Groupe de travail Réseau	C. Jennings, Cisco Systems	
Request for Comments : 5341	V. Gurbani, Bell Laboratories, Alcatel-Lucent	
RFC mise à jour : 3966		
Catégorie : Sur la voie de la normalisation		
Traduction Claude Brière de L'Isle	septembre 2008	

Registre des paramètres d'identifiant de ressource universelle (URI) de l'IANA 

Statut du présent mémoire
Le présent document spécifie un protocole Internet sur la voie de la normalisation pour la communauté de l'Internet. Il appelle à la discussion et à des suggestions pour son amélioration. Prière de se référer à l'édition actuelle des "Normes officielles des protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

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 "tel" d’identifiant de ressource universelle (URI, Uniform Resource Identifier (URI) et leurs valeurs. Il remplit le registre avec les paramètres définis dans la spécification de l’URI "tel", ainsi qu’avec les paramètres des extensions à l’URI "tel" définis pour la portabilité du numéro et des groupes de circuits.
Table des matières
1. Introduction	1
2. Terminologie	1
3. Utilisation du registre	1
4. Considérations relatives à l'IANA	2
4.1 Registre des paramètres d’URI tel	2
4.2 Politique d’enregistrement pour les paramètres d’URI tel	3
5. Considérations pour la sécurité	3
6. Remerciements	3
7. Références	3
7.1 Références normatives	3
7.2 Références pour information	4
Adresse des auteurs	4
Déclaration complète de droits de reproduction	4

 	1.	Introduction

L’URI tel [RFC3966] définit un URI qui peut être utilisé pour représenter des ressources identifiées par des numéros de téléphone. L’URI tel, comme de nombreux autres URI, fournit l’extensibilité à travers la définition de nouveaux paramètres d’URI et de nouvelles valeurs pour les paramètres existants. Cependant, la RFC 3966 ne spécifie pas un registre de l’IANA où de tels paramètres et valeurs peuvent être énumérés et normalisés. La présente spécification crée un tel registre.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans le BCP  14, [RFC2119].

 	3.	Utilisation du registre

Les paramètres et valeurs d’URI tel pour ces paramètres DOIVENT être documentés dans une RFC ou autre spécification permanente et directement accessible au public afin d’être enregistrés par l’IANA. Cette documentation DOIT expliquer pleinement la syntaxe, l’usage prévu, et la sémantique du paramètre. L’intention de cette exigence est d’assurer l’interopérabilité entre des mises en œuvre indépendantes, et d’empêcher les collisions accidentelles d’espace de noms entre des mises en œuvre de caractéristiques différentes.

Les documents qui définissent les paramètres ou valeurs de paramètre d’URI tel DOIVENT être enregistrés auprès de l’IANA, comme décrit à la Section 4. La politique d’enregistrement de l’IANA pour de tels paramètres est "Spécification exigée, expert désigné" et est discutée plus en détails au paragraphe 4.2.

Certains paramètres d’URI tel acceptent seulement un ensemble de valeurs prédéfinies de paramètres tandis que d’autres peuvent prendre n’importe quelle valeur. Il y a aussi des paramètres qui n’ont pas de valeurs du tout ; ils sont utilisés comme des fanions.

Les paramètres d’URI qui prennent des valeurs prédéfinies prennent normalement un grand nombre de valeurs. Enregistrer chacune de ces valeurs, ou créer un sous registre pour chacun de ces paramètre n’est pas approprié. On a plutôt choisi d’enregistrer les valeurs de paramètre d’URI par référence. C’est-à-dire, l’entrée dans le registre des paramètres d’URI pour un certain paramètre d’URI contient des références aux RFC qui définissent les nouvelles valeurs de ce paramètre.

Par conséquent, le registre des paramètre d’URI tel contient une colonne qui indique si chaque paramètre accepte ou non une valeur. La colonne peut contenir "Pas de valeur" ou "Contrainte". Un "Contrainte" dans la colonne implique que certaines valeurs prédéfinies existent pour ce paramètre et que la RFC qui l’accompagne ou autre spécification permanente et directement accessible au public devrait être consultée pour trouver l’ensemble de valeurs acceptées. Un "Pas de valeur" dans la colonne implique que le paramètre est utilisé soit comme fanion, soit n’a pas d’ensemble de valeurs prédéfinies. La RFC ou autre spécification permanente et directement accessible au public d’accompagnement devrait fournir plus d’informations sur la sémantique du paramètre.

 	4.	Considérations relatives à l'IANA

Cette spécification crée un nouveau registre de l’IANA nommé "Paramètres d’URI tel".

 	4.1	Registre des paramètres d’URI tel
Les nouveaux paramètres d’URI tel et les nouvelles valeurs pour Ies paramètres d’URI tel existants DOIVENT être enregistrés par l’IANA.

Lors de l’enregistrement d’un nouveau paramètre d’URI tel, les informations suivantes DOIVENT être fournies :

o	Nom du paramètre.

o	Si le paramètre accepte seulement un ensemble de valeurs prédéfinies.

o	Référence à la RFC ou autre spécification permanente et directement accessible au public qui définit le paramètre et les nouvelles valeurs.

Quand on enregistre une nouvelle valeur pour un paramètre d’URI tel existant, les informations suivantes DOIVENT être fournies :

o	Nom du paramètre.

o	Référence à la RFC ou autre spécification permanente et directement accessible au public qui fournit la nouvelle valeur.

Le Tableau 1 contient les valeurs initiales de ce registre.

Nom de paramètre	Valeurs prédéfinies	Référence
isub	Contrainte	[RFC3966]
isub-encoding	Contrainte	[RFC4715]
ext	Contrainte	[RFC3966]
phone-context	Contrainte	[RFC3966]
enumdi 	Pas de valeur	[RFC4759]
npdi	Pas de valeur	[RFC4694]
rn    	Contrainte	[RFC4694]
rn-context	Contrainte	[RFC4694]
cic  	Contrainte	[RFC4694]
cic-context	Contrainte	[RFC4694]
tgrp 	Contrainte	[RFC4904]
trunk-context	Contrainte	[RFC4904]

Tableau 1 : Registre IANA de paramètres d’URI tel

 	4.2	Politique d’enregistrement pour les paramètres d’URI tel
Selon la terminologie de la [RFC5226] et les actions qui s’accordent à un tel rôle, la politique d’enregistrement pour les paramètres d’URI tel devra être "spécification exigée, expert désigné" (la première impliquant implicitement la seconde).

L’expert désigné, quand il délibère sur la question d’inclure un nouveau paramètre dans le registre d’URI tel, peut utiliser les critères fournis ci-dessous pour prendre une décision (cette liste n’est pas exhaustive mais représente les questions à prendre en considération pour prendre une décision équitable) :

o	Si l’URI tel – avec le paramètre considéré – va être converti en un URI utilisé par d’autres protocoles de signalisation comme le protocole d’initialisation de session (SIP, Session Initiation Protocol) [RFC3261] ou [H.323], alors l’expert doit considérer si ce paramètre encapsule simplement les informations de signalisation qui ne sont pas significatives pour le traitement des demandes dans le domaine de l’URI converti. Par exemple, certains paramètres du sous système utilisateur (ISUP) de réseau numérique à intégration de services (RNIS) [Q.764] n’ont pas de corrolaire équivalent dans SIP ; donc, leur présence ou absence dans un URI SIP ne va pas entraver les règles normales de traitement de cet URI. D’autres paramètres peuvent affecter les règles de traitement normal associées à l’URI ; dans ce cas, l’expert doit examiner avec attention les ramifications, si il en est, de la présence de tels paramètres.

o	Certains paramètres d’un URI tel peuvent être facultétifs. Ces paramètres agissent comme des métadonnées sur l’identifiant dans l’URI tel. Les paramètres facultatifs devraient fournir des informations supplémentaires sur le service auquel ils s’appliquent plutôt que d’agir comme activateurs de ce service. Le service doit continuer d’être invoqué et fonctionner normalement même en l’absence de ces paramètres.

 	5.	Considérations pour la sécurité

Le registre de ce document n’a pas par lui-même d’implications de sécurité. Cependant, comme mentionné dans la [RFC3427], une raison importante de la gestion des extension à SIP par l’IETF est de s’assurer que toutes les extensions et paramètres sont capables de fournir un usage sûr. Les publications de RFC qui prennent en charge les enregistrement de paramètres décrits dans cette spécification DOIVENT fournir des considération de sécurité détaillées pour eux.

 	6.	Remerciements

La structure de ce document vient de la [RFC3969], qui est le travail équivalent fait dans le domaine de SIP pour établir un registre. Ted Hardie, Alfred Hoenes, Jon Peterson, et Jonathan Rosenberg ont fourni des commentaires substantiels qui ont amélioré ce document.

Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, et Glen Zorn ont fourni des retours durant la revue de l’IESG et la revue Gen-ART.

 	7.	Références
 	7.1	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)

[RFC3966]	H. Schulzrinne, "L'URI tel pour les numéros de téléphone", décembre 2004. (MàJ par RFC5341) (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

 	7.2	Références pour information

[H.323]	Recommandation UIT-T H.323, "Systèmes de communication multimédia fondés sur le paquet", UIT, Genève, 2006.

[Q.764]	Recommandation UIT-T Q.764, "Système de signalisation n° 7 : Procédures de signalisation du sous système utilisateur RNIS", décembre 1999.

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

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

[RFC3969]	G. Camarillo, "Registre des paramètres d'identifiant de ressource uniforme (URI) de l'IANA pour le protocole d'initialisation de session (SIP)", décembre 2004. (BCP0099)

 	Adresse des auteurs

Cullen Jennings	Vijay K. Gurbani	
Cisco Systems	Bell Laboratories, Alcatel-Lucent	
170 West Tasman Drive	2701 Lucent Lane	
Mailstop SJC-21/2	Room 9F-546	
San Jose, CA  95134	Lisle, IL  60532	
USA	USA	
téléphone :  +1 408 902-3341	téléphone :  +1 630 224-0216	
mél : fluffy@cisco.com	mél : vkg@alcatel-lucent.com	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2008).

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

Le présent document et les informations y contenues sont fournies 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, le IETF TRUST 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 ci-encloses ne violent 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.