Groupe de travail Réseau	G. Camarillo, Ericsson	
Request for Comments : 3968	décembre 2004	
BCP 98		
Met à jour la RFC 3427		
Catégorie : Bonne pratiques actuelles	Traduction Claude Brière de L'Isle	

Registre des paramètres de champ d'en-tête de l'IANA 
pour le protocole d'initialisation de session (SIP)

Statut de ce mémoire
Ce document spécifie les bonnes pratiques actuelles sur l'Internet pour la communauté de l'Internet, et demande des discussions et suggestions pour son amélioration. La diffusion du présent mémoire n'est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2004).

Résumé
Le présent document crée un registre de l'Autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Number Authority) pour les paramètres et valeurs de paramètres de champ d'en-tête du protocole d'initialisation de session (SIP, Session Initiation Protocol). Il fait aussi la liste des paramètres et valeurs de paramètre déjà existants à utiliser comme entrées initiales de ce registre.
Table des matières
1. Introduction	1
2. Terminologie	1
3. Utilisation du registre	2
4. Considérations relatives à l'IANA	2
4.1 Sous registre Paramètres de champ d'en-tête	2
4.2 Politique d'nregistrement pour les paramètres de champ d'en-tête SIP	5
5. Considérations sur la sécurité	5
6. Remerciements	5
7. Références normatives	5
Adresse de l'auteur	6
Déclaration complète de droits de reproduction	6

 	1.	Introduction

La [RFC3261] permet de définir de nouveaux paramètres de champ d'en-tête et de nouvelles valeurs de paramètres. Cependant, la RFC 3261 omet de définir un registre IANA pour eux. Le présent document crée un tel registre.

La [RFC3427] documente le processus pour étendre SIP. Le présent document met à jour la RFC 3427 en spécifiant comment définir et enregistrer de nouveaux paramètres de champ d'en-tête et valeurs de paramètres SIP.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	3.	Utilisation du registre

Les paramètres de champ d'en-tête et valeurs de paramètres SIP DOIVENT être documentés dans une RFC afin d'être enregistrés par l'IANA. Cette documentation DOIT expliquer pleinement la syntaxe, l'usage de destination, et la sémantique du paramètre ou de la valeur du paramètre. L'intention de cette exigence est d'assurer l'interopérabilité entre des mises en œuvre indépendantes, et empêcher des collisions accidentelles d'espaces de noms entre des mises en œuvre de caractéristiques différentes.

Noter que ce registre, à la différence des autres registres de protocoles, ne traite que des paramètres et valeurs de paramètres définis dans des RFC (c'est-à-dire, qu'il n'a pas d'arborescence d'extensions de fabricants). La [RFC3427] documente les problèmes concernant les nouvelles extensions de SIP qui pourraient porter atteinte à la sécurité, augmenter considérablement la complexité du protocole, ou les deux. Les nouveaux paramètres et valeurs de paramètres doivent être documentés dans des RFC par suite de ces problèmes.

Les RFC qui définissent des paramètres de champ d'en-tête ou valeurs de paramètres SIP DOIVENT les enregistrer auprès de l'IANA comme décrit ci-dessous.

Les paramètres de champ d'en-tête et valeurs de paramètres SIP enregistrés sont à considérer comme des "mots réservés". Afin de préserver l'interopérabilité, les paramètres et valeurs de paramètres enregistrés DOIVENT être utilisés d'une façon cohérente avec celle décrite dans leur RFC de définition. Les mises en œuvre NE DOIVENT PAS utiliser des paramètres de champ d'en-tête ou valeurs de paramètre SIP "privés" ou "définis en local" qui entrent en conflit avec les paramètres enregistrés.

Noter que bien que les paramètres de champ d'en-tête et valeurs de paramètres SIP non enregistrés puissent être utilisés dans des mises en œuvre, les développeurs sont avertis que l'usage de tels paramètres est risqué. De nouveaux paramètres de champ d'en-tête et valeurs de paramètres peuvent être enregistrés à tout moment, et il n'est pas garanti que ces nouveaux paramètres ou valeurs de paramètres enregistrés n'entrent pas en conflit avec des paramètre non enregistrés actuellement utilisés.

Certains paramètres de champ d'en-tête SIP n'acceptent qu'un ensemble de valeurs de paramètre prédéfinies. Par exemple, un paramètre indiquant le protocole de transport utilisé peut n'accepter que les jetons prédéfinis TCP, UDP, et SCTP comme valeurs valides. Enregistrer toutes les valeurs de paramètres pour tous les paramètres de champ d'en-tête SIP de ce type exigerait un grand nombre de sous registres. À la place, on a choisi d'enregistrer les valeurs de paramètres par référence. C'est-à-dire que l'entrée dans le registre des paramètres pour un champ d'en-tête donné contient des références aux RFC qui définissent les nouvelles valeurs du paramètre. Les références aux RFC qui définissent les valeurs de paramètres apparaissent entre des doubles crochets dans le registre.

Ainsi, le registre des paramètres de champ d'en-tête contient une colonne qui indique si chaque paramètre accepte ou non seulement un ensemble de valeurs  prédéfinies. Les mises en œuvre de paramètres qui ont un "oui" dans cette colonne doivent trouver toutes les valeurs valides du paramètre dans les RFC fournies en référence.

 	4.	Considérations relatives à l'IANA

La Section 27 de la [RFC3261] crée un registre de l'IANA pour les noms de méthodes, les noms de champ d'en-tête, les codes d'avertissement, les codes d'état, et les étiquettes d'option. La présente spécification crée un nouveau sous registre pour les paramètres de champ d'en-tête sous le registre Paramètres SIP.

 	4.1	Sous registre Paramètres de champ d'en-tête
La majorité des champs d'en-tête SIP peuvent être étendus par la définition de nouveaux paramètres. Les nouveaux paramètres de champ d'en-tête SIP sont enregistrés par l'IANA. Lors de l'enregistrement d'un nouveau paramètre pour un champ d'en-tête ou d'une nouvelle valeur pour un paramètre, les informations suivantes DOIVENT être fournies  :
o	champ d'en-tête dans lequel le paramètre peut apparaître,
o	nom du paramètre de champ d'en-tête enregistré,
o	si le paramètre accepte seulement un ensemble de valeurs prédéfinies,
o 	une référence à la RFC où le paramètre est défini et à toute RFC qui définit de nouvelles valeurs pour le paramètre. Les références aux RFC qui définissent des valeurs de paramètre apparaissent entre doubles crochets dans le registre.

Des paramètres qui peuvent apparaître dans des champs d'en-tête différents PEUVENT avoir le même nom. Cependant, les paramètres qui peuvent apparaître dans le même champ d'en-tête DOIVENT avoir des noms différents.

Voici les valeurs initiales pour ce sous registre.

Champ d'en-tête	Nom de paramètre	Valeurs prédéfinies	Référence
Accept	q	Non	[RFC 3261]
Accept-Encoding	q	Non	[RFC 3261]
Accept-Language	q	Non	[RFC 3261]
Authorization	algorithm	Oui	[RFC 3261] [[RFC 3310]]
Authorization	auts	Non	[RFC 3310]
Authorization	cnonce	Non	[RFC 3261]
Authorization	nc	Non	[RFC 3261]
Authorization	nonce	Non	[RFC 3261]
Authorization	opaque	Non	[RFC 3261]
Authorization	qop	Oui 	[RFC 3261]
Authorization	realm	Non	[RFC 3261]
Authorization	response	Non	[RFC 3261]
Authorization	uri	Non	[RFC 3261]
Authorization	username	Non	[RFC 3261]
Authentication-Info	cnonce	Non	[RFC 3261]
Authentication-Info	nc	Non	[RFC 3261]
Authentication-Info	nextnonce	Non	[RFC 3261]
Authentication-Info	qop	Oui 	[RFC 3261]
Authentication-Info	rspauth	Non	[RFC 3261]
Call-Info	purpose	Oui 	[RFC 3261]
Contact	expires	Non	[RFC 3261]
Contact	q	Non	[RFC 3261]
Content-Disposition	handling	Oui 	[RFC 3261]
Event	id	Non	[RFC 3265]
From 	tag	Non	[RFC 3261]
P-Access-Network-Info	cgi-3gpp	Non	[RFC 3455]
P-Access-Network-Info	utran-cell-id-3gpp	Non	[RFC 3455]
P-Charging-Function-Addresses	ccf 	Non	[RFC 3455]
P-Charging-Function-Addresses	ecf	Non	[RFC 3455]
P-Charging-Vector	icid-value	Non	[RFC 3455]
P-Charging-Vector	icid-generated-at	Non	[RFC 3455]
P-Charging-Vector	orig-ioi	Non	[RFC 3455]
P-Charging-Vector	term-ioi	Non	[RFC 3455]
P-DCS-Billing-Info	called	Non	[RFC 3603]
P-DCS-Billing-Info	calling	Non	[RFC 3603]
P-DCS-Billing-Info	charge	Non	[RFC 3603]
P-DCS-Billing-Info	locroute	Non	[RFC 3603]
P-DCS-Billing-Info	rksgroup	Non	[RFC 3603]
P-DCS-Billing-Info	routing	Non	[RFC 3603]
P-DCS-LAES	content	Non	[RFC 3603]
P-DCS-LAES	key	Non	[RFC 3603]
P-DCS-Redirect	count	Non	[RFC 3603]
P-DCS-Redirect	redirector-uri	Non	[RFC 3603]
Proxy-Authenticate	algorithm	Oui 	[RFC 3261] [[RFC 3310]]
Proxy-Authenticate	domain	Non	[RFC 3261]
Proxy-Authenticate	nonce	Non	[RFC 3261]
Proxy-Authenticate	opaque	Non	[RFC 3261]
Proxy-Authenticate	qop 	Oui 	[RFC 3261]
Proxy-Authenticate	realm	Non	[RFC 3261]
Proxy-Authenticate	stale	Oui 	[RFC 3261]
Proxy-Authorization	algorithm	Oui 	[RFC 3261] [[RFC 3310]]
Proxy-Authorization	auts	Non	[RFC 3310]
Proxy-Authorization	cnonce	Non	[RFC 3261]
Proxy-Authorization	nc	Non	[RFC 3261]
Proxy-Authorization	nonce	Non	[RFC 3261]
Proxy-Authorization	opaque	Non	[RFC 3261]
Proxy-Authorization	qop	Oui 	[RFC 3261]
Proxy-Authorization	realm	Non	[RFC 3261]
Proxy-Authorization	response	Non	[RFC 3261]
Proxy-Authorization	uri 	Non	[RFC 3261]
Proxy-Authorization	username	Non	[RFC 3261]
Reason	cause	Oui 	[RFC 3326]
Reason	text	Non	[RFC 3326]
Retry-After	duration	Non	[RFC 3261]
Security-Client	alg	Oui 	[RFC 3329]
Security-Client	ealg	Oui 	[RFC 3329]
Security-Client	d-alg	Oui 	[RFC 3329]
Security-Client	d-qop	Oui 	[RFC 3329]
Security-Client	d-ver	Non	[RFC 3329]
Security-Client	mod	Oui 	[RFC 3329]
Security-Client	port1	Non	[RFC 3329]
Security-Client	port2	Non	[RFC 3329]
Security-Client	prot	Oui 	[RFC 3329]
Security-Client	q	Non	[RFC 3329]
Security-Client	spi	Non	[RFC 3329]
Security-Server	alg	Oui 	[RFC 3329]
Security-Server	ealg	Oui 	[RFC 3329]
Security-Server	d-alg	Oui 	[RFC 3329]
Security-Server	d-qop	Oui 	[RFC 3329]
Security-Server	d-ver	Non	[RFC 3329]
Security-Server	mod	Oui 	[RFC 3329]
Security-Server	port1	Non	[RFC 3329]
Security-Server	port2	Non	[RFC 3329]
Security-Server	prot	Oui 	[RFC 3329]
Security-Server	q	Non	[RFC 3329]
Security-Server	spi	Non	[RFC 3329]
Security-Verify	alg	Oui 	[RFC 3329]
Security-Verify	ealg	Oui 	[RFC 3329]
Security-Verify	d-alg	Oui 	[RFC 3329]
Security-Verify	d-qop	Oui 	[RFC 3329]
Security-Verify	d-ver	Non	[RFC 3329]
Security-Verify	mod	Oui 	[RFC 3329]
Security-Verify	port1	Non	[RFC 3329]
Security-Verify	port2	Non	[RFC 3329]
Security-Verify	prot	Oui 	[RFC 3329]
Security-Verify	q	Non	[RFC 3329]
Security-Verify	spi	Non	[RFC 3329]
Subscription-State	expires	Non	[RFC 3265]
Subscription-State	reason	Oui 	[RFC 3265]
Subscription-State	retry-after	Non	[RFC 3265]
To	tag	Non	[RFC 3261]
Via	branch	Non	[RFC 3261]
Via	comp	Oui 	[RFC 3486]
Via	maddr	Non	[RFC 3261]
Via	received	Non	[RFC 3261]
Via	rport	Non	[RFC 3581]
Via	ttl	Non	[RFC 3261]
WWW-Authenticate	algorithm	Oui 	[RFC 3261] [[RFC 3310]]
WWW-Authenticate	domain	Oui 	[RFC 3261]
WWW-Authenticate	nonce	Non	[RFC 3261]
WWW-Authenticate	opaque	Non	[RFC 3261]
WWW-Authenticate	qop	Oui 	[RFC 3261]
WWW-Authenticate	realm	Non	[RFC 3261]
WWW-Authenticate	stale	Oui 	[RFC 3261]

 	4.2	Politique d'nregistrement pour les paramètres de champ d'en-tête SIP

Selon la terminologie de la [RFC2434], la politique d'enregistrement pour les paramètres de champ d'en-tête et valeurs de paramètres SIP devra être par "consensus de l'IETF".

Pour les besoins du présent registre, le paramètre ou la valeur de paramètre pour lequel l'enregistrement de l'IANA est demandé DOIT être défini par une RFC. Il n'est pas obligé que cette RFC soit sur la voie de la normalisation.

 	5.	Considérations sur la sécurité

Le registre du présent document ne pose pas par lui-même de problème de sécurité. Cependant, comme mentionné dans la RFC 3427, une importante raison de la gestion des extensions de SIP par l'IETF est de s'assurer que toutes les extensions et paramètres sont capables de fournir une utilisation sûre. Les publications des RFC de prise en charge des enregistrements de paramètre qui décrivent cette spécification DOIVENT fournir des considérations de sécurité détaillées pour eux.

 	6.	Remerciements

Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule, et Allison Mankin ont fourni d'utiles commentaires sur le présent document.

 	7.	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3265]	A.B. Roach, "Notification d'événement spécifique du protocole d'initialisation de session (SIP)", juin 2002. (MàJ par RFC6446) (Remplacée par la RFC6665) 

[RFC3310]	A. Niemi, J. Arkko, V. Torvinen, "Authentification de résumé dans le protocole de transfert Hypertext (HTTP) utilisant l'authentification et l'accord de clés (AKA)", septembre 2002. (Information)

[RFC3326]	H. Schulzrinne, D. Oran, G. Camarillo, "Champ d'en-tête Reason pour le protocole d'initialisation de session (SIP)", décembre 2002. (P.S.)

[RFC3329]	J. Arkko et autres, "Accord de mécanisme de sécurité pour le protocole d'initialisation de session (SIP)", janvier 2003. (P.S.)

[RFC3427]	A. Mankin et autres, "Processus des changements au protocole d'initialisation de session (SIP)", BCP 67, décembre  2002. (Remplacée par RFC5727)

[RFC3455]	M. Garcia-Martin, E. Henrikson, D. Mills, "Extensions d'en-têtes privés (P-Header) au protocole d'initialisation de session (SIP) pour le projet en partenariat de 3ème génération (3GPP)", janvier 2003. (Information)

[RFC3486]	G. Camarillo, "Compression du protocole d'initialisation de session (SIP)", février 2003. (MàJ par RFC5049) (P.S.)

[RFC3581]	J. Rosenberg, H. Schulzrinne, "Extension au protocole d'initialisation de session (SIP) pour l'acheminement à réponse symétrique", août 2003. (P.S.)

[RFC3603]	W. Marshall et F. Andreasen, éd., "Extensions privées de mandataire à mandataire du protocole d'initialisation de session (SIP) pour la prise en charge de l'architecture PacketCable de signalisation d'appel répartie", octobre 2003. (Information)

 	Adresse de l'auteur

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

mél : Gonzalo.Camarillo@ericsson.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2004).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.