6. Définition et enregistrement d'un espace de noms URN

6.1. Vue d'ensemble

Parce que l'espace des espaces de noms URN est lui-même géré, la définition d'un espace de noms URN devrait accorder une attention particulière aux éléments suivants (SHOULD) :

1. L'objet de l'espace de noms URN.

2. La syntaxe des URN attribués au sein de l'espace de noms URN, y compris la syntaxe interne et les effets attendus des r-component ou q-component. (La syntaxe et l'interprétation des f-component sont définies dans la RFC 3986.)

3. Le processus d'attribution des URN au sein de l'espace de noms URN.

4. Les implications de sécurité liées à l'attribution des URN au sein de l'espace de noms URN et à l'utilisation des URN attribués.

5. Tout problème potentiel d'interopérabilité avec les URN attribués au sein de l'espace de noms URN.

6. Facultativement, le processus de résolution des URN attribués au sein de l'espace de noms URN.

La section consacrée au remplissage du modèle (section 6.4) explique ces questions plus en détail. Bien que les modèles d'enregistrement soient les mêmes dans tous les cas, des procédures légèrement différentes sont utilisées selon l'origine de l'enregistrement.

6.2. Politique et processus d'enregistrement : enregistrements communautaires

La politique d'enregistrement de base pour les espaces de noms URN est l'"Expert Review" telle que définie dans le document sur les considérations relatives à l'IANA [RFC5226]. Pour les espaces de noms URN ou leurs définitions qui sont destinés à devenir des normes ou des parties constitutives de normes, le résultat du processus d'"Expert Review" est censé être un rapport plutôt que des instructions données à l'IANA pour qu'elle agisse (voir ci-dessous). Les étapes clés sont les suivantes :

1. Remplir le modèle d'enregistrement d'espace de noms URN (voir la section 6.4 et l'annexe A). Cela peut se faire dans le cadre d'un Internet-Draft ou d'une spécification d'une autre série, bien que cela ne soit pas une obligation.

2. Envoyer le modèle rempli à la liste de discussion [email protected] pour examen.

3. Si nécessaire pour répondre aux commentaires reçus, répéter les étapes 1 et 2.

4. Si les Designated Experts approuvent la demande et qu'aucune action de normalisation n'est en jeu, l'IANA enregistrera le NID demandé. Si une normalisation est anticipée, les Designated Experts prépareront un rapport et le transmettront à l'organe d'approbation des normes approprié (l'IESG dans le cas de l'IETF) ; l'IANA n'enregistrera le NID demandé qu'après avoir reçu des directives de cet organe et une copie du rapport d'"Expert Review".

Un enregistrement d'espace de noms URN peut être révisé en mettant à jour le modèle d'enregistrement, en suivant les mêmes étapes que celles décrites ci-dessus pour les nouveaux enregistrements. Un enregistrement révisé doit décrire les différences par rapport aux versions antérieures et devrait signaler tout particulièrement les changements pertinents dans les technologies sous-jacentes ou les processus de gestion de l'espace de noms URN (MUST, SHOULD).

L'expérience acquise à ce jour avec les demandes d'enregistrement d'espaces de noms URN a montré que les déclarants ne comprennent parfois pas d'emblée certaines des subtilités des espaces de noms URN et que le fait de définir l'espace de noms URN sous la forme d'une spécification permet aux déclarants de formuler clairement leur "contrat" avec la communauté d'utilisateurs visée. Par conséquent, bien que la politique d'enregistrement des espaces de noms URN formels soit l'"Expert Review" et qu'une spécification (distincte du modèle d'enregistrement) ne soit pas strictement exigée, les déclarants devraient fournir une spécification stable documentant la définition de l'espace de noms URN et développant les questions décrites dans le présent document (SHOULD).

Parce que le nommage peut être difficile et source de controverses, il est vivement encouragé que les déclarants d'espaces de noms URN et les Designated Experts travaillent ensemble dans un esprit de bonne foi et de compréhension mutuelle afin de parvenir à un consensus approximatif (voir [RFC7282]) sur le traitement des demandes d'enregistrement. Ils sont également encouragés à faire intervenir une expertise supplémentaire dans la discussion si cela peut aider à apporter un éclairage ou à résoudre des questions.

En particulier lorsque les itérations du processus d'enregistrement se prolongent, les Designated Experts sont censés prendre des précautions raisonnables pour éviter les "situations de course" sur les NID proposés et, si de telles situations se présentent, encourager les candidats à régler eux-mêmes tout conflit.

6.3. Politique et processus d'enregistrement : procédure accélérée pour les organisations de développement de normes, les sociétés savantes et organismes similaires

L'IETF reconnaît que des situations se présenteront dans lesquelles des espaces de noms URN seront créés pour intégrer des normes existantes et établies, en particulier des normes d'identificateurs, ou pour refléter des connaissances, une terminologie ou des méthodes d'organisation de l'information qui se situent bien en dehors du champ d'action de l'IETF ou des connaissances thématiques probables de ses Designated Experts. Dans les situations où la demande d'enregistrement émane d'une organisation de développement de normes reconnue, d'une société savante ou de leurs représentants désignés, ou est autorisée par eux, une procédure quelque peu différente est disponible, à l'option de cet organisme :

1. Le modèle d'enregistrement d'espace de noms URN est rempli et soumis comme aux étapes 1 et 2 de la section 6.2.

2. Une spécification est requise, qui reflète les normes ou spécifications externes nécessaires ou y renvoie. Une publication dans la série des RFC ou par le biais d'un processus de l'IETF (par exemple, une publication comme Internet-Draft) n'est pas attendue et ne serait appropriée que dans des circonstances très inhabituelles.

3. Les examens menés sur la liste de discussion et par les Designated Experts sont strictement consultatifs, les décisions concernant les conseils à accepter et la durée à allouer au processus relevant strictement du contrôle de l'organisme externe.

4. Lorsque cet organisme conclut que la demande est suffisamment mûre, son ou ses représentants demanderont à l'IANA de procéder à l'enregistrement du NID, et l'IANA le fera.

Les décisions concernant la reconnaissance de l'entité demandeuse en tant qu'organisation de développement de normes ou société savante relèvent de la responsabilité de l'IESG.

Un modèle similaire à celui-ci a déjà été défini pour les organisations de développement de normes reconnues qui souhaitent enregistrer des types de médias. Le document décrivant ce mécanisme [RFC6838] fournit un peu plus d'informations sur l'approche générale.

6.4. Remplissage du modèle

Un modèle pour définir et enregistrer un espace de noms URN est fourni à l'annexe A. La présente section décrit les considérations relatives au remplissage du modèle.

6.4.1. Objet

La section "Purpose" du modèle décrit des questions telles que :

1. Les types de ressources identifiées par les URN attribués au sein de l'espace de noms URN.

2. La portée et l'applicabilité des URN attribués au sein de l'espace de noms URN ; cela peut inclure des informations sur la communauté d'utilisation (par exemple, une nation, un secteur, une technologie ou une organisation particuliers), si les URN attribués seront utilisés sur des réseaux publics ou privés, etc.

3. En quoi la communauté visée (et la communauté Internet dans son ensemble) bénéficiera de l'utilisation ou de la résolution des URN attribués.

4. Le rapport entre l'espace de noms URN et les espaces de noms URN, schémas d'URI et systèmes d'identificateurs non-URN existants, et en quoi il les complète.

5. Les types d'applications logicielles qui peuvent utiliser ou résoudre les URN attribués (par exemple, en différenciant des espaces de noms URN disparates, en identifiant des ressources de manière persistante, ou en résolvant et en accédant de manière significative aux services associés à l'espace de noms URN).

6. Si des services de résolution sont disponibles ou le seront (et, le cas échéant, la nature ou l'identité de ces services). Des exemples de sémantique et de syntaxe de q-component et (lorsqu'ils seront normalisés) de r-component sont utiles ici, même si des définitions détaillées sont fournies ailleurs ou ultérieurement.

7. Si l'espace de noms URN ou sa définition est censé devenir une partie constitutive d'une norme en cours d'élaboration au sein de l'IETF ou d'un autre organisme de normalisation reconnu.

6.4.2. Syntaxe

La section "Syntax" du modèle contient :

1. Une description de la structure des URN au sein de l'espace de noms URN, en conformité avec la syntaxe URN fondamentale. La structure peut être décrite au moyen d'une définition formelle (par exemple à l'aide de l'ABNF [RFC5234]), d'un algorithme de génération d'URN conformes, ou d'une expression régulière permettant d'analyser le nom en ses parties constitutives ; alternativement, la structure peut être opaque.

2. Toute règle particulière d'encodage des caractères pour les URN attribués (par exemple, quel caractère devrait toujours être utilisé pour les guillemets).

3. Les règles permettant de déterminer l'URN-equivalence entre deux noms de l'espace de noms URN. De telles règles devraient toujours avoir pour effet d'éliminer les faux négatifs qui pourraient autrement résulter de la comparaison. Si cela est approprié et utile, il est possible de renvoyer à des règles d'équivalence particulières définies dans la spécification URI [RFC3986] ou à la section 3 du présent document. Des exemples de règles d'URN-equivalence incluent l'équivalence entre caractères majuscules et minuscules dans le NSS, entre groupements avec et sans trait d'union dans le nom, ou entre guillemets simples et guillemets doubles. Il peut également exister des considérations d'encodage particulières propres à l'espace de noms, en particulier pour les URN qui contiennent des formes intégrées de noms issus de systèmes d'identificateurs non-URN. (Notez qu'il ne s'agit pas d'énoncés normatifs concernant une quelconque bonne pratique liée à la gestion des relations entre caractères en général ; de tels énoncés se limitent à un espace de noms URN particulier uniquement.)

4. Toute considération particulière nécessaire pour se conformer à la syntaxe URN. Cela s'applique particulièrement au cas des systèmes d'identificateurs non-URN existants qui sont utilisés dans le contexte des URN. Par exemple, si un système d'identificateurs non-URN est utilisé dans des contextes autres que les URN, il peut recourir à des caractères qui sont réservés dans la syntaxe URN. Cette section devrait signaler tout caractère de ce type et exposer les correspondances nécessaires pour se conformer à la syntaxe URN. Normalement, cela sera traité en encodant le caractère en pourcentage comme spécifié à la section 2.1 de la spécification URI [RFC3986] et comme discuté à la section 1.2.2 de la présente spécification.

5. Toute considération particulière concernant la signification des q-component (par exemple, des mots clés) ou des f-component (par exemple, des termes prédéfinis) dans le contexte de cet espace de noms URN.

6.4.3. Attribution

La section "Assignment" du modèle décrit des questions telles que :

1. Les mécanismes ou autorités d'attribution des URN aux ressources. Elle devrait préciser clairement si l'attribution est complètement ouverte (par exemple, selon une procédure particulière telle que le premier arrivé, premier servi (FCFS)), complètement fermée (par exemple, pour une organisation privée) ou limitée de diverses manières (par exemple, déléguée à des autorités reconnues par une organisation particulière) ; si elle est limitée, elle devrait expliquer comment devenir attributaire de noms ou comment demander l'attribution de noms auprès des autorités d'attribution existantes.

2. Les méthodes permettant de garantir que les URN au sein de l'espace de noms URN sont uniques. Par exemple, les noms peuvent être attribués séquentiellement ou selon un processus bien défini par une autorité unique, l'attribution peut être répartie entre des autorités déléguées individuellement responsables du respect des règles d'unicité, ou les URN peuvent être créés indépendamment selon un algorithme qui garantit lui-même l'unicité.

6.4.4. Sécurité et vie privée

La section "Security and Privacy" du modèle décrit tout problème potentiel lié à la sécurité et à la vie privée concernant l'attribution, l'utilisation et la résolution des noms au sein de l'espace de noms URN. Des exemples de tels problèmes incluent :

• Les conséquences de la production de faux négatifs et de faux positifs lors de la comparaison aux fins de l'URN-equivalence (voir la section 3.1 de la présente spécification et "Issues in Identifier Comparison for Security Purposes" [RFC6943]).

• La fuite d'informations privées lorsque des noms sont communiqués sur l'Internet public.

• Le potentiel de collecte de répertoires (directory harvesting).

• Divers problèmes discutés dans les lignes directrices relatives aux considérations de sécurité dans les RFC [RFC3552] et dans les considérations relatives à la vie privée pour les protocoles Internet [RFC6973]. En particulier, notez le texte des considérations relatives à la vie privée pour l'espace de noms Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) [RFC7254], qui peut fournir un modèle utile pour de tels cas.

6.4.5. Interopérabilité

La section "Interoperability" doit spécifier tout problème potentiel connu lié à l'interopérabilité (MUST). Les exemples incluent une éventuelle confusion avec d'autres espaces de noms URN, systèmes d'identificateurs non-URN ou schémas d'URI en raison de la syntaxe (par exemple, l'encodage en pourcentage de certains caractères) ou de la portée (par exemple, des domaines d'intérêt qui se chevauchent). Si possible, les préoccupations qui surgissent lors de l'enregistrement d'un espace de noms URN (par exemple, en raison de la syntaxe ou de la portée d'un système d'identificateurs non-URN) devraient être résolues dans le cadre du processus d'enregistrement ou parallèlement à celui-ci.

6.4.6. Résolution

La section "Resolution" doit spécifier si des mécanismes de résolution sont prévus ou anticipés pour les URN attribués au sein de l'espace de noms URN (MUST).

Si une résolution est prévue, cette section devrait préciser si l'organisation qui attribue des URN au sein de l'espace de noms URN a l'intention d'exploiter ou de recommander des services de résolution pour les URN de cet espace de noms URN (SHOULD). En outre, si l'organisation attributrice a l'intention de mettre en œuvre un enregistrement pour des services de résolution annoncés publiquement (par exemple, à l'aide d'un système développé dans l'esprit des principes architecturaux et des descriptions de services d'origine pour la résolution d'URN [RFC2276] [RFC2483]), alors cette section devrait énumérer ou référencer les exigences pour être annoncé publiquement par l'organisation attributrice (SHOULD). En outre, cette section devrait décrire toute considération particulière relative au traitement des r-component dans le contexte de cet espace de noms URN (SHOULD).

6.4.7. Informations complémentaires

La section "Additional Information" contient des informations qui seraient utiles à ceux qui cherchent à comprendre cet enregistrement ou son rapport avec d'autres enregistrements, telles que des comparaisons avec des espaces de noms URN existants qui pourraient sembler se chevaucher.

Cette section du modèle est facultative.