Sous-espace de noms d'URN de l'IETF
pour les paramètres de protocole enregistrés

Statut de ce mémoire

Le présent document spécifie les bonnes pratiques actuelles de l’Internet pour la communauté de l’Internet, et appelle à la discussion et à des suggestions d’améliorations. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2003). Tous droits réservés.

Résumé

Le présent document décrit une nouvelle sous délégation pour l’espace de noms d’URN 'ietf' pour les éléments de protocole enregistrés. L’espace de noms d’URN 'ietf' est défini dans la RFC2648 comme une racine pour les URI persistants qui se réfèrent aux ressources définies par l’IETF.

1. Introduction

De temps en temps, les normes de l’IETF requièrent l’enregistrement de divers éléments de protocole dans des répertoires centraux bien connus. L’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) tient ce répertoire central et reçoit des directives de l’IETF sur quels éléments y ajouter, comment les ajouter et quand le faire. L’IANA tient des listes d’éléments comme tous les numéros d’accès alloués, les types de supports MIME, les numéros d’entreprises, etc.

Au fil du temps s’est développé le besoin d’être capable de faire référence à ces éléments comme des URI dans divers schémas. Dans le passé, ceci était fait au coup par coup ce qui conduit facilement à des problèmes d’interopérabilité. Le présent document crée une nouvelle sous délégation en dessous de l’espace de noms d’URN [RFC2141] "ietf" [RFC2648] appelée 'params' qui agit comme un mécanisme normalisé pour désigner les éléments enregistrés pour les normes de l’IETF. Toute allocation dans ce sous espace doit être spécifiée dans une RFC selon le processus de consensus de l’IETF et inclure le gabarit qui figure à la Section 4.

2. Terminologie

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

3. Spécificités du sous espace de noms IETF

Nom du sous espace de noms : params

Déclarant de l’espace de noms : Équipe d’ingénierie de l’Internet (The Internet Engineering Task Force)

Déclaration de structure :

L’espace de noms est principalement opaque. L’IANA, comme opérateur du registre, peut recevoir des suggestions pour les noms à allouer, mais se réserve le droit d’allouer tout nom qu’elle désire, dans le cadre des lignes directrices fixées par l’IESG. Le caractère deux points (":") est utilisé pour noter un concept très limité de hiérarchie. Si un caractère deux points est présent, les éléments des deux côtés de ce caractère sont des noms valides. En général, si un nom a un caractère deux points, l’élément sur le côté gauche représente alors une classe des éléments qui contiendraient d’autres éléments de cette classe. Par exemple, un nom peut être alloué à la liste entière des codes de type d’enregistrement de ressource du DNS ainsi que pour chaque code individuel. L’URN pour la liste pourrait ressembler à :

urn:ietf:params:dns:rr-type-codes

tandis que l’URN pour le code de type d’enregistrements SOA pourrait ressembler à :

urn:ietf:params:dns:rr-type-codes:soa

Documentation auxiliaire pertinente : [RFC3406], [RFC2648], [RFC2141]

Considérations d’unicité d’identifiant :

L’IESG utilise le processus de consensus de l’IETF pour s’assurer que les sous espaces de noms génèrent des noms uniques au sein de ce sous espace. L’IESG délègue à l’IANA la tâche de s’assurer que les noms des sous espaces eux-mêmes sont uniques. Tant que l’IESG ne spécifie pas autre chose, l’IANA a pour instruction de s’assurer de l’unicité en comparant le nom à allouer à la liste des noms alloués antérieurement. Dans le cas de conflit, l’IANA doit demander une nouvelle chaîne au déclarant jusqu’à ce que le conflit soit réglé.

Considérations de persistance d’identifiant :

Une fois qu’un nom a été alloué, il NE DOIT PAS être réalloué pour un besoin différent. Les règles fournies pour les allocations de valeurs au sein d’un sous espace de noms DOIVENT être construites de façon telle que la signification des valeurs ne puisse pas changer. Ce mécanisme d’enregistrement n’est pas approprié pour la désignation de valeurs dont la signification peut changer au fil du temps. Si une valeur change au fil du temps, l’allocation DOIT désigner le conteneur ou le concept qui contient la valeur, et non la valeur elle-même. Par exemple, si un paramètre appelé 'foo' a une valeur qui change dans le temps, il est valide de créer le nom 'urn:ietf:params:foo-params:foo' qui identifie ce 'créneau'. Il n’est pas valide de créer en fait un nom qui contient cette valeur sauf si c’est une valeur persistante et unique comme un numéro de version.

Processus d’allocation d’identifiant :

Les identifiants ne sont alloués qu’après qu’un élément ou numéro de protocole particulier a été enregistré auprès de l’IANA en utilisant des politiques et procédures standard, ou documentées dans une RFC qui décrit un protocole en cours de normalisation. Cela signifie que la fonction de 'portier' pour les allocations est le processus de "consensus de l’IETF" documenté dans la [RFC2434].

Processus de résolution d’identifiant : Pour l’instant, aucun mécanisme de résolution n’est défini.

Règles d’équivalence lexicale :

L’équivalence lexicale est réalisée par la correspondance exacte de chaîne conformément aux règles de la syntaxe d’URN décrites dans la [RFC2141]. Précisément, du fait de la définition de la syntaxe d’URN, la norme 'stringprep' de la [RFC3454] ne s’applique pas.

Conformité à la syntaxe d’URN : Il n’y a pas de caractère réservé supplémentaire.

Mécanisme de validation : aucun.

Portée : Mondiale.

4. Allocation des noms

La création d’un nouveau nom de registre sera simple pour la plupart des registres plats. Les seuls éléments exigés seront le nom du registre, une référence aux documents pertinents, une déclaration des répertoires de documents actuels/proposés qui contiennent les données d’autorité pour le registre, et une déclaration qui spécifie quels éléments dans le registre ont la valeur à utiliser dans l’URN. Dans la plupart des cas, ce dernier élément sera la valeur d’indice allouée par l’IANA.

Les registres plus complexes (des paramètres du DNS par exemple) vont devoir répéter ces informations pour chacun des sous espaces de noms. Il devrait aussi être clair si un nom est ou non alloué au sous espace de noms lui-même (c'est-à-dire, 'urn:ietf:params:dns:rr-types' est il valide par lui-même et si oui, que désigne t-il ?).

Le gabarit :

Nom de registre : nom du sous espace de noms. Dans de nombreux cas, ce devrait être le même nom que celui dont l’IANA appelle le registre lui-même.

Spécification : documents pertinents publiés par l’IETF qui définissent le registre et les éléments qui le composent.

Répertoire : pointeur sur la localisation 'actuelle' du registre dans le répertoire de paramètres du protocole ou les RFC pertinentes qui documentent les éléments désignés. Cette valeur va changer avec le temps à mesure que l’entité qui assure la maintenance du répertoire déplace les fichiers et ou les serveurs des fichiers. Il n’est pas conçu comme un lien permanent avec le nom de fichier mais comme une indication pour l’IANA de ce que la transposition initiale devrait être.

Valeur d’indice : description de la façon dont une valeur enregistrée est à incorporer dans la forme d’URI. Ceci DOIT inclure les détails de toute transformation qui pourrait être nécessaire pour que la chaîne résultante se conforme aux règles syntaxiques d’URN et toute canonisation nécessaire pour que la comparaison de chaîne sensible à la casse donne les équivalences attendues.

Le processus pour demander qu’un URN soit alloué est actuellement de mettre le gabarit ci-dessus ou une référence à ce gabarit dans une section de considérations relatives à l’IANA du document de spécification. D’autres processus plus automatiques pourront être proposés ultérieurement si il y a une demande pour cela.

5. Considérations pour la sécurité

Aucune qui ne soit déjà inhérente à l’utilisation des URN. Les considérations de sécurité pour les URN en général se trouvent dans la [RFC2141]. D’autres considérations de sécurité pour une méthode de résolution d’URN spécifique se trouvent dans le Système de découverte dynamique de délégation (DDDS) Partie quatre : application de résolution des identifiants de ressource universels (URI) [RFC3404] qui fait partie d’une série commençant par la partie un : système DDDS complet [RFC3401].

6. Considérations relatives à l’IANA

Le présent document fait peser une charge nouvelle et significative sur l’IANA dans la mesure où il peut exiger qu’un processus d’allocation supplémentaire se produise pour chaque nouveau registre de l’IANA. Pour minimiser la charge administrative de l’IANA, tout enregistrement d’espace de noms de paramètre est très clair sur les critères d’inclusion dans cet espace de noms.

Définir un registre qui satisfait aux contraintes d’un espace de noms d’URN va imposer une discipline plus stricte qui devrait s’appuyer sur des collaborations occasionnelles pour la création et la maintenance de ce registre.

7. Déclaration de 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 pourraient ê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 le BCP 11. 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.

8. Références normatives

[RFC2141] R. Moats, "Syntaxe des URN", mai 1997.

[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)

[RFC2648] R. Moats, "Espace de nom d'URN pour les documents de l'IETF", août 1999. (Information)

[RFC3401] M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie I : DDDS complet", octobre 2002. (Info.)

[RFC3404] M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie IV : Identifiants de ressource uniformes (URI)", octobre 2002. (P.S.)

[RFC3406]  L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom, "Mécanismes de définition d'espace de noms de noms de ressource uniforme (URN)", octobre 2002. (BCP0066)

[RFC3454] P. Hoffman et M. Blanchet, "Préparation de chaînes internationalisées ("stringprep")", décembre  2002. (P.S.)

9. Adresse des auteurs

Graham Klyne

Nine by Nine

mél : GK-IETF@ninebynine.org

URI : http://www.ninebynine.net/

10. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Le présent document et les traductions qui en sont faites peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou à d’autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.