RFC3406 page - 12 - Daigle & autres

BCP66

Groupe de travail Réseau

L. Daigle, Thinking Cat Enterprises

Request for Comments : 3406

D.W. van Gulik, WebWeaving

BCP : 66

R. Iannella, IPR Systems

RFC rendue obsolète : 2611

P. Faltstrom, Cisco

Catégorie : Bonnes pratiques actuelles

octobre 2002

Traduction Claude Brière de L'Isle




Mécanisme de définition de l'espace de noms des noms de ressource uniformes (URN)



Statut de ce mémoire

Le présent document spécifie les bonnes pratiques actuelles pour la communauté de l'Internet et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.


Notice de copyright

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


Résumé

Le présent document pose les définitions générales et les mécanismes pour établir les "espaces de noms" des noms de ressource uniformes (URN, Uniform Resource Names). Le groupe de travail URN a défini une syntaxe pour les URN dans la RFC2141, ainsi que proposé des mécanismes pour leur résolution et leur utilisation dans les applications de l'Internet dans les RFC3401 et RFC3405. Le tout s'appuie sur le concept des "espaces de noms" individuels au sein de la structure d'URN. À part le concept des espaces de noms, l'utilisation des identifiants existants dans les URN a été exposé dans la RFC2288.


Table des matières

1. Introduction 1

2. Qu'est-ce qu'un espace de nom d'URN ? 2

3. Types d'espaces de nom d'URN (enregistrement) 2

3.1 Espaces de noms formels expérimentaux 2

3.2 Espaces de noms informels 3

3.3 Espaces de noms formels 3

4. Enregistrement d'espace de noms d'URN, mise à jour et processus d'allocation de NID 4

4.1 Expérimental 4

4.2 Informel 4

4.3 Formel 5

5. Considérations pour la sécurité 6

6. Considérations relatives à l'IANA 6

7. Références 6

Appendice A – Gabarit de définition d'espace de noms d'URN 6

Appendice B -- Illustration 9

B.1 Exemple de gabarit 9

B.2 Étapes pratiques de l’enregistrement 10

Appendice C -- Changements par rapport à la RFC2611 11

C.1 Changements détaillés du document 11

Adresse des auteurs 12

Déclaration complète de droits de reproduction 12



1. Introduction


Les noms de ressource uniformes (URN, Uniform Resource Names) sont des identifiants de ressource qui ont pour exigence spécifique de permettre l'identification d'une ressource indépendamment de sa localisation, ainsi que la longévité de la référence. Les URN font partie de la famille plus large des identifiants de ressource universels (URI, Uniform Resource Identifier) de la [RFC3305] avec le but spécifique de fournir une dénomination persistante des ressources.


Le présent document pose deux hypothèses clés :


Hypothèse n° 1 :

L'allocation d'un URN est un processus géré.

C'est-à-dire que toutes les chaînes qui se conforment à la syntaxe d'URN sont nécessairement des URN valides. Un URN est alloué conformément aux règles d'un espace de noms particulier (en termes de syntaxe, de sémantique, et de traitement).


Hypothèse n° 2 :

L'espace de l'espace de noms d'URN est géré.

C'est-à-dire que tous les espaces de noms d'URN syntaxiquement corrects (selon la définition de la syntaxe d'URN) ne sont pas des espaces de nom d'URN valides. Un espace de nom d'URN doit avoir une définition reconnue afin d'être valide.


L’objet du présent document est de mettre en évidence le mécanisme de définition d’un espace de noms explicite et d’en fournir un gabarit, ainsi que de donner le mécanisme pour associer un identifiant (appelé identifiant d’espace de noms ou NID , Namespace ID) qui est enregistré auprès de l’autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority).


Noter que le présent document se restreint à la description du processus de création des espaces de noms d’URN. Si on désire la "résolution" des identifiants d’URN ainsi créés, un processus d’enregistrement distinct dans un répertoire mondial des NID, tel que celui fourni par le système DDDS [RFC3401], est nécessaire. Voir dans la [RFC3405] des informations sur l’obtention de l’enregistrement dans le répertoire mondial des NID de DDDS.


2. Qu'est-ce qu'un espace de nom d'URN ?


Pour les besoins des URN, un "espace de noms" est une collection d’identifiants univoques. C’est à dire que les identifiants ne sont jamais alloués à plus d’une ressource, et ne sont jamais réalloués à une ressource différente. Une seule ressource peut cependant avoir plus d’un URN alloué pour des objets différents. L’espace de noms d’URN lui-même a un identifiant afin :

- d’assurer l’unicité mondiale des URN,

- de fournir (lorsque désiré) une réplique à la structure de l’identifiant.


Par exemple, de nombreux systèmes d’identifiant peuvent utiliser des chaînes de nombres comme identifiants (par exemple, ISBN, ISSN, numéros de téléphone). On peut concevoir qu’il peut y avoir certains nombres qui sont des identifiants valides dans deux systèmes différents d’identifiants établis. Utiliser des désignations différentes pour les deux collections assure que deux URN ne seront pas les mêmes pour des ressources différentes (car chaque collection est obligée d’allouer chaque identifiant de façon univoque).


Le développement d’une structure d’identifiants, et par là, d’une collection d’identifiants, est un processus qui est par nature dépendant des exigences de la communauté qui définit l’identifiant, de la façon dont ils seront alloués, et des utilisations auxquelles ils donneront lieu. Toutes ces questions sont spécifiques de la communauté individuelle qui cherche à définir un espace de noms (par exemple, une communauté d’édition, une association de libraires, des développeurs de protocoles, etc.) ; cela sort du domaine d’application du groupe de travail URN de l’IETF.


Le présent document souligne les processus par lesquels une collection d’identifiants qui satisfont à certaines contraintes (unicité d’allocation, etc.) peut devenir un espace de noms d’URN de bonne foi en obtenant un NID. En bref, un gabarit de définition d’espace de noms est achevé par le dépôt auprès de l’IANA, et l’allocation d’un NID. Les détails du processus et les possibilités des chaînes de NID sont développés ci-après.


3. Types d'espaces de nom d'URN (enregistrement)


Il y a trois catégories d’espaces de noms d’URN qui sont définies ici, distinguées par le niveau de service attendu et les procédures requises pour l’enregistrement. Les processus d’enregistrement pour chacun de ces types d’espace de noms sont données au paragraphe 4.0.


3.1 Espaces de noms formels expérimentaux

Ils ne sont pas enregistrés explicitement par l’IANA. Ils prennent la forme :


X-<NID>


Aucune disposition n’est prise pour éviter la collision des NID expérimentaux ; ils sont destinés à être utilisés au sein de contextes internes ou d’expériences limitées.


3.2 Espaces de noms informels

Ce sont des espaces de noms d’URN de plein droit, avec tous les droits et exigences associés de ce fait. Les espaces de noms informels peuvent être enregistrés dans des services d’enregistrement mondiaux. Ils doivent suivre les principes généraux d’un espace de noms d’URN bien géré – fournir une identification de ressources persistante, et une allocation univoque des chaînes d’identifiant. Les espaces de noms informels et formels (qui sont décrits plus loin) différent par l’allocation du NID. L’IANA va allouer un NID alphanumérique pour enregistrer les espaces de noms informels, selon le processus décrit à la section 4.


3.3 Espaces de noms formels

Un espace de noms formel peut être demandé, soumis à l’examen de l’IETF, dans les cas où la publication de la proposition de NID et l’espace de noms sous-jacent va apporter un avantage pour un sous-ensemble des utilisateurs de l’Internet. C’est à dire qu’une proposition de NID formel, si elle est acceptée, doit remplir une fonction pour l’Internet mondial, non limitée aux utilisateurs d’une communauté ou de réseaux non connectés à l’Internet. Par exemple, un NID qui est destiné à désigner des recherches en physique est demandé. Si cette demande de NID exige que l’utilisateur se serve d’un réseau ou service privé qui n’est pas ouvert à l’utilisateur général de l’Internet, cela ne sera pas une demande acceptable pour un NID formel. L’intention est que, alors que la communauté de ceux qui peuvent activement utiliser les noms alloués au sein de ce NID peut être restreinte (mais pas moins importante pour autant) l’utilisation potentielle des noms au sein de ce NID est ouverte à tout utilisateur de l’Internet.


Il est prévu que les NID formels peuvent s’appliquer aux espaces de noms dont certains aspects ne sont pas pleinement ouverts. Par exemple, un espace de noms peut comporter l’usage d’un registre à gestion privée ou protégé, à accès tarifé pour l’allocation des URN dans l’espace de noms, mais cela peut cependant être encore avantageux pour certains utilisateurs de l’Internet si les services associés ont des protocoles d’accès librement publiés.


En plus des informations d’enregistrement de base définies dans le formulaire d’enregistrement (voir l’Appendice A) une demande d’espace de nom formel doit être accompagnée de considérations documentées du besoin d’un nouvel espace de noms et de l’avantage pour la communauté d’établir formellement l’espace de noms d’URN proposé.


De plus, comme le but des URN est de fournir une identification persistante, certaines considérations comme la longévité et la possibilité de maintenir l’espace de noms doivent être données. Le groupe de travail URN a longuement discuté la question de trouver des mesures objectives pour prévoir (à priori) la poursuite du succès d’un espace de noms. Aucune conclusion n’a pu être trouvée -- beaucoup dépend de facteurs qui dépassent complètement la portée technique de l’espace de noms. Cependant, l’expérience collective de la communauté de l’IETF contient bien un trésor d’informations sur les facteurs techniques qui vont empêcher la longévité de l’identification. L’IESG peut choisir de ne pas publier une RFC proposant un espace de noms si le consensus de la communauté de l’IETF est qu’elle contient des erreurs techniques qui vont empêcher la persistance de l’identification (ou sérieusement dégrader sa possibilité).


Le groupe de travail URN a discuté des choses suivantes :

- l’organisation qui entretient l’espace de noms d’URN devrait prouver sa stabilité et sa capacité à entretenir l’espace de noms d’URN sur une longue période, et/ou il devrait être clair que l’espace de noms peut continuer d’être utilisable/utile si l’organisation cesse d’être capable de l’alimenter ;

- elle devrait démontrer ses capacités et sa compétence à allouer des noms. Cela devrait améliorer la vraisemblance de la persistance (par exemple pour minimiser les occurrences de conflits) ;

- elle devrait s’engager à ne pas réallouer les noms existants et à permettre que les vieux noms continuent d’être valides, même si les possesseurs ou allocataires de ces noms ne sont plus membres ou clients de cette organisation. Cela ne signifie pas qu’il doit y avoir une résolution de ces noms, mais que le nom ne doit pas se résoudre en informations fausses ou périmées, et qu’ils ne doit pas être réalloué.


Ces aspects, bien que difficiles à quantifier objectivement, devraient être pris en considération par les organisations/personnes qui envisagent le développement d’un espace de noms d’URN formel, et ils devront être présents lors de l’évaluation des mérites techniques de toute proposition d’espace de noms formel.



4. Enregistrement d'espace de noms d'URN, mise à jour et processus d'allocation de NID


Différent niveaux de divulgation sont attendus/définis pour les espaces de noms. Conformément au niveau du forum de discussion ouvert qui entoure la divulgation, un espace de noms d’URN peut recevoir ou peut demander un identifiant particulier. Le document "Considérations relatives à l’IANA" [RFC2434] suggère le besoin de spécifier des mécanismes de mise à jour pour les enregistrements – qui a autorité pour le faire ?, à quels moments ?, et ce que sont les procédures. Comme les URN sont destinés à être d’une utilité persistante, peu de changements (si il en est) devraient être apportés à l’interprétation structurelle des chaînes d’URN (par exemple, ajouter ou supprimer des règles d’équivalence lexicale qui peuvent affecter l’interprétation des identifiants d’URN déjà alloués). Cependant, il peut être important d’introduire des éclaircissements, d’étendre la liste des allocataires d’URN autorisés, etc., dans le cours naturel de la vie d’un espace de noms. Les processus spécifiques sont décrits ci-dessous.


La liste officielle des espaces de noms d’URN enregistrés est tenue par l’IANA. Les enregistrements d’espace de noms d’URN sont actuellement envoyés dans le répertoire FTP anonyme :


http://www.iana.org/assignments/urn-namespaces


Voir dans la [RFC3232] la localisation actuelle du registre de l’IANA.


Les procédures d’enregistrement et de maintenance varient légèrement d’un type d’espace de noms (comme défini à la section 3) à l’autre.


4.1 Expérimental

Ils ne sont pas explicitement enregistrés auprès de l’IANA. Ils prennent la forme :


X-<NID>


Aucune disposition n’est prise pour éviter la collision des NID expérimentaux ; ils sont destinés à être utilisés au sein de contextes expérimentaux internes ou limités.


Comme il n’y a pas d’enregistrement, aucune procédure de maintenance des enregistrements n’est nécessaire.


4.2 Informel

Ils sont enregistrés auprès de l’IANA et un numéro de séquence leur est alloué comme identifiant, avec le format :


"urn-" <numéro>


où <numéro> est choisi par l’IANA sur la base du premier arrivé, premier servi (voir la [RFC2434]).


Les déposants devraient envoyer une copie du gabarit d’enregistrement (voir à l’Appendice A) dûment complété, à :


urn-nid@apps.ietf.org


et compter une période de discussion de deux semaines pour éclaircir l’expression des informations d’enregistrement et des suggestions d’améliorations techniques à la proposition d’espace de noms.


Après que les suggestions d’éclaircissements des informations d’enregistrement ont été incorporées, le formulaire peut être soumis pour l’allocation d’un NID à :


iana@iana.org


Les seules restrictions sur <numéro> sont qu’il consiste strictement en chiffres et qu’il ne peut pas faire que le NID dépasse les limitations de longueur posées par la syntaxe d’URN ([RFC2141]).


Les enregistrements peuvent être mis à jour par le déposant d’origine, ou par une entité désignée par le déposant, par une mise à jour du formulaire d’enregistrement, en le soumettant à la liste de discussion pour une autre période de deux semaines, et en le resoumettant finalement à l’IANA, comme décrit ci-dessus.

4.3 Formel

Les NID formels sont alloués via consensus de l’IETF , comme défini dans la [RFC2434] :


"Consensus de l’IETF – les nouvelles valeurs sont allouées par le processus de consensus de l’IETF. Précisément, les nouvelles allocations sont faites via des RFC approuvées par l’IESG. Normalement, l’IESG va chercher des informations sur les projets d’allocations auprès des personnes appropriées (par exemple, un groupe de travail pertinent s’il en existe un)."


Donc, l’application formelle de NID est faite via la publication d’une RFC à travers les processus standard de l’IETF. Il n’est pas nécessaire que la RFC soit en cours de normalisation, mais elle sera soumise à l’examen de l’IESG et à son acceptation selon les lignes directrices écrites ici (ainsi que les lignes directrices sur la publication des RFC standard). Le gabarit défini à l’Appendice A peut être inclus au titre d’une RFC qui définit d’autres aspects de l’espace de noms ou il peut être mis en avant comme RFC de plein exercice. Le gabarit proposé devrait être envoyé à la liste de diffusion


urn-nid@apps.ietf.org


pour permettre une période de discussion de deux semaines pour préciser l’expression des informations d’enregistrement, avant que l’IESG ne relise le document.


La RFC doit inclure une section "Considérations sur l’espace de noms", qui souligne telle qu’elle apparaît la nécessité d’un nouvel espace de noms (c’est-à-dire, en quoi les espaces de noms existants ne satisfont pas aux exigence de celui qui formule la proposition).


Ces considérations peuvent inclure :

- Les procédures d’allocation d’URN

- La résolution/délégation d’URN

- Le type de ressources à identifier

- Le type de services à prendre en charge


Note : On s’attend à ce que plus d’un espace de noms puisse servir au même objet "fonctionnel" ; l’intention de la section "Considérations sur les espaces de noms" est de fournir un enregistrement de la "diligence" du proposant à explorer les possibilités existantes, pour l’édification de l’IESG.


La RFC doit aussi inclure une section "Considérations de communauté", qui indique les dimensions dans lesquelles le proposant espère que sa communauté sera capable de bénéficier de la publication de cet espace de noms ainsi que comment un utilisateur de l’Internet général sera capable d’utiliser l’espace si il le souhaite. Les considérations potentielles incluent :

- l’allocation et l’utilisation ouverte d’identifiants au sein de l’espace de noms,

- le fonctionnement ouvert de serveurs de résolution pour l’espace de noms (serveur)

- la création de logiciels qui puissent résoudre de façon cohérente et accéder aux services pour l’espace de nom (client).


La RFC doit inclure une section "Considérations relatives l’IANA", indiquant que le document inclut un enregistrement de NID d’URN qui sera à entrer dans le registre de l’IANA des NID d’URN.


Une chaîne de NID particulière est demandée, et elle est allouée par consensus de l’IETF (comme défini dans la [RFC2434]) avec les contraintes supplémentaires que la chaîne de NID ne doit pas :

- être un NID déjà enregistré,

- commencer par "x-" (voir le Type I ci-dessus)

- commencer par "urn-" (voir Type II ci-dessus)

- commencer par "XY-", où XY est toute combinaison de deux lettres ASCII (voir la Note, ci-dessous)

- faire moins de trois lettres de long.


Note : Toutes les combinaisons de deux lettres, et combinaisons de deux lettres suivies par "-" et toute séquence de caractères de NID valide sont réservées pour une utilisation potentielle comme NID fondé sur le code de pays pour d’éventuels enregistrements nationaux d’espaces de noms d’URN. La définition et la portée des règles d’allocation de responsabilité pour de tels espaces de noms sortent du domaine d’application du présent document.


Les enregistrements peuvent être révisés par la mise à jour de la RFC au moyen des processus standard de mise à jour de RFC de l’IETF (voir dans la [RFC2026] un exposé des processus de l’IETF). Dans tous les cas, un document révisé, sous la forme d’un nouveau projet Internet, doit être publié, et le gabarit mis à jour proposé doit être diffusé sur la liste de discussion urn-nid, en permettant une période de révision de deux semaines avant de procéder à la publication du nouveau document RFC.


5. Considérations pour la sécurité


Le présent document se concentre largement sur la fourniture de mécanismes pour la déclaration d’informations publiques . Nominalement, ces déclarations devraient présenter un profil de sécurité relativement faible ; cependant, il y a toujours le danger de "mystification" et de fourniture de fausses informations. Les information contenues dans ces déclarations devraient être considérées comme purement indicatives.


6. Considérations relatives à l'IANA


Le présent document décrit les processus d’enregistrement des espaces de noms d’URN, et a des implications pour l’IANA en termes de registres à tenir. Dans tos les cas, l’IANA devrait allouer le NID approprié (informel ou formel) comme décrit ci-dessus, une fois qu’un expert désigné par l’IESG a confirmé que les étapes requises du processus d’enregistrement ont été accomplies. Le présent document définit les processus pour remplacer ceux définis dans la [RFC2611].


7. Références


[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times"


[RFC1737] K. Sollins et L. Masinter, "Exigences fonctionnelles pour les noms de ressource uniformes", décembre 1994.


[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)


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


[RFC2276] K. Sollins, "Principes d'architecture de la résolution de nom de ressource uniforme", janvier 1998. (MàJ par RFC3401) (Information)


[RFC2288] C. Lynch, C. Preston, R. Daniel, "Utilisation des identifiants bibliographiques existants comme noms de ressource uniformes", février 1998. (Information)


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


[RFC2611] L. Daigle et autres, "Mécanismes de définition d'espace de nom d'URN", juin 1999. (Obsolète, voir RFC3406)


[RFC3232] J. Reynolds, "Numéros alloués : la RFC 1700 est remplacée par une base de données en ligne", janvier 2002.


[RFC3305] M. Mealling et R. Denenberg, "Rapport au groupe d'intérêt conjoint W3C/IETF Planification des URI : Identifiants de ressource universels (URI), URL, et noms de ressource uniformes (URN) : éclaircissements et recommandations", août 2002.


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


[RFC3405] M. Mealling, "Système de découverte dynamique de délégation (DDDS) Partie V : Procédures d'allocation URI.ARPA", octobre 2002. (BCP0065)


Appendice A – Gabarit de définition d'espace de noms d'URN


La définition d’un espace de noms d’URN est accomplie en remplissant le gabarit d’informations suivant. À part fournir un mécanisme de divulgation de la structure de l’espace de noms d’URN, ces informations sont destinées à être utiles pour :

- les entités qui cherchent à avoir un URN alloué dans un espace de noms (si c’est applicable)

- les entités qui cherchent à fournir des résolveurs d’URN pour un espace de noms (si c’est applicable).


Ceci est particulièrement important pour des communautés qui évaluent la possibilité d’utiliser une portion d’un espace de noms d’URN existant plutôt que de créer le leur.


Les demandes d’espaces de noms d’URN formels doivent aussi documenter "Considérations d’espace de noms", "Considérations de communauté" et "Considérations relatives à l’IANA", comme décrit au paragraphe 4.3.


Les informations dans le gabarit sont les suivantes :


Namespace ID (identifiant d’espace de noms) :

Alloué par l’IANA. Dans le cas d’un enregistrement de NID formel, une chaîne de NID particulière peut être requise.


Informations d’enregistrement :

Ce sont des informations pour identifier la version particulière des informations d’enregistrement :

- numéro de version d’enregistrement : commençant à 1, incrémenté de 1 à chaque nouvelle version

- date d’enregistrement : date de soumission à l’IANA, en utilisant le format prévu dans [ISO8601] : AAAA-MM-JJ


Déposant de l’enregistrement d’espace de noms :

Cela inclut :

Organisation déposant l’enregistrement

Nom

Adresse

Personne de contact désignée

Nom

Coordonnées (au moins un parmi : mèl, téléphone, adresse postale)


Déclaration de structure syntaxique :

Cette section devrait préciser toutes les caractéristiques de structure des identifiants dans cet espace de noms. Au minimum, cette description peut être utilisée pour introduire la terminologie utilisée dans les autres sections. Cette structure peut aussi être utilisée pour déterminer des approches réalistes de mise en antémémoire/raccourcis ; les avertissement appropriés devraient être fournis. Si il y a des règles spécifiques de codage de caractères (par exemple, quel caractère devrait toujours être utilisé pour des guillemets simples) ils devraient être énumérés ici.


Les réponses devraient inclure, mais sans s’y limiter :

- si la structure est opaque (aucune exposition)

- une expression régulière pour analyser l’identifiant selon ses composants, y compris les autorités de dénomination.


Documentation auxiliaire pertinente :

Cette section devrait énumérer toutes les RFC, normes, ou autre documentation publiée qui définit ou explique tout ou partie de la structure d’espace de noms.


Les réponses devraient inclure, mais sans s’y limiter :

- les RFC qui précisent la syntaxe de l’espace de noms,

- les autres documents qui définissent la communauté (par exemple, ISO) qui précisent la syntaxe des identifiants dans l’espace de noms,

- le matériel explicatif qui présente l’espace de noms.


Considérations sur l’unicité des identifiants :

Cette section devrait traiter des exigences d’allocation univoque des identifiants d’URN – ils sont alloués au plus à une ressource, et ne sont pas réalloués.


(Noter que la définition de "ressource" est très large ; par exemple, des informations sur "Le temps aujourd’hui" peuvent être considérées comme une seule ressource, bien que son contenu soit dynamique.)


Les réponses possibles incluent, mais sans s’y limiter :

- l’exposition de la structure des identifiants, et les partages de l’espace des identifiants entre les autorités d’allocation qui sont individuellement chargées de respecter les règles d’unicité,

- les identifiants sont alloués en séquence,

- les informations sont cachées ; l’espace de noms est opaque.


Considérations sur la persistance des identifiants :

Bien que la non réallocation des identifiants d’URN assure qu’un URN va persister à identifier une ressource particulière même après la fin de la "durée de vie de la ressource", certaines considérations devraient prendre en compte la persistance de la possibilité d’utiliser l’URN. Ceci est particulièrement important dans le cas d’espaces de noms d’URN qui fournissent une résolution mondiale.


Les réponses possibles incluent, mais sans s’y limiter :

- les considérations de qualité de service.


Processus d’allocation d’identifiants :

Cette section devrait préciser les mécanismes et/ou les autorités d’allocation des URN aux ressources. Elle devrait préciser si l’allocation est complètement ouverte, ou si elle est limitée, comment devenir un alloueur d’identifiants, et/ou obtenir une allocation par les autorités d’allocation existantes.


Les réponses pourraient inclure, sans s’y limiter :

- l’allocation est complètement ouverte, suivant un algorithme particulier,

- l’allocation est déléguée à des autorités reconnues par une organisation particulière (par exemple, la Fondation des identifiants d’objet contrôle l’espace d’allocation DOI et sa délégation)

- l’allocation est complètement fermée (par exemple, pour une organisation privée).


Processus de résolution des identifiants :

Si un espace de noms est destiné à être accessible pour une résolution mondiale, il doit être enregistré dans un système de découverte de résolution (RDS, Resolution Discovery System, voir la [RFC2276]) comme DDDS. La résolution se fait alors conformément au processus standard de résolution d’URI, et aux mécanismes de la RDS. Ce que cette section devrait préciser sont les exigences pour devenir un résolveur reconnu des URN dans cet espace de noms (et étant cela, d’être inscrit dans le registre RDS).


Les réponses peuvent inclure, mais sans s’y limiter :

- l’espace de noms n’est pas inscrit auprès d’un RDS ; ceci n’est pas pertinent,

- le reflet de la résolution est complètement ouvert, avec un mécanisme pour mettre à jour un RDS approprié,

- la résolution est contrôlée par des entités auxquelles l’allocation a été déléguée.


Règles d’équivalence lexicale :

Si il y a des algorithmes particuliers pour déterminer l’équivalence entre deux identifiants dans l’espace de noms sous-jacent (donc, dans la chaîne d’URN elle-même) les règles peuvent être fournies ici.


Quelques exemples sont :

- l’équivalence entre des groupements avec un trait d’union et sans trait d’union dans la chaîne d’identifiant,

- l’équivalence entre simple guillemets et doubles guillemets,

- les équivalences définies par l’espace de noms entre des caractères spécifiques, tels que le "caractère X avec ou sans signe diacritique".


Noter que ces déclarations ne sont en aucun cas normatives d’aucune sorte de bonnes pratiques pour le traitement des équivalences entre caractères ; ce sont des déclarations qui se limitent à refléter les propres règles de l’espace de noms.


Conformité à la syntaxe d’URN :

Cette section devrait rapporter toutes considérations particulières exigées pour se conformer à la syntaxe d’URN. Ceci est particulièrement applicable dans le cas des systèmes de dénomination traditionnels qui sont utilisés dans le contexte des URN.


Par exemple, si un espace de noms est utilisé dans des contextes autres que celui des URN, il peut faire usage de caractères qui sont réservés dans la syntaxe d’URN.


Cette section devrait marquer tous ces caractères, et souligner les transpositions nécessaires pour se conformer à la syntaxe d’URN. Normalement, cela sera traité par un codage du symbole en hexadécimal.


Par exemple, voir la section sur les SICI dans la [RFC2288].


Mécanisme de validation :

À part de tenter la résolution d’un URN, un espace de noms d’URN peut fournir des mécanismes de "validation" d’URN – c’est-à-dire, pour déterminer si une certaine chaîne est actuellement un URN alloué de façon valide. Il y a deux problèmes derrière cela : 1) les utilisateurs ne devraient pas "deviner" les URN dans un espace de noms ; 2) lorsque l’espace de noms d’URN est fondé sur un système d’identifiants existant, il peut n’être pas le cas que tous les identifiants existants soient alloués dès le premier jour. Une attente raisonnable serait que la ressource associée à chaque URN résultant soit quelque peu en relation avec la chose identifiée par le système d’identifiant original, mais ces ressources peuvent ne pas exister pour chaque identifiant original. Par exemple, même si il était créé un espace de noms d’URN fondé sur le numéro de téléphone, il ne semble pas que tous les numéros de téléphone deviendraient immédiatement des URN "valides", et cela pourrait se résoudre en utilisant des mécanismes quelconques décrits au titre de l’enregistrement de l’espace de noms.


Les mécanismes de validation pourraient être :

- une grammaire syntaxique,

- un service en ligne,

- un service hors ligne.


Portée :

Cette section devrait décrire la portée de l’utilisation des identifiants dans cet espace de noms. À part des considérations sur les espaces de noms privés contre public, cette section est importante pour l’évaluation de l’applicabilité du NID demandé. Par exemple, un espace de noms prétendant traiter des "numéros de sécurité sociale" devrait avoir une portée mondiale et englober toutes les structures de numéro de sécurité sociale (ce qui est peu probable). D’un autre côté, au niveau national, il est raisonnable de proposer un espace de noms d’URN pour "les numéros de sécurité sociale" de ce pays.


Appendice B -- Illustration


B.1 Exemple de gabarit


L’exemple suivant est fourni pour les besoins de l’illustration du gabarit de NID d’URN décrit dans l’Appendice A. Bien qu’il se fonde sur un hypothétique "espace de noms générique Internet" qui a été discuté de façon informelle au sein du groupe de travail URN, il y a encore des problèmes techniques et d’infrastructure qui sont à résoudre avant qu’un tel espace de noms puisse être décrit de façon correcte et complète.


Identifiant d’espace de noms : À allouer


Informations d’enregistrement :

Version 1

Date : <date de la soumission>


Déclarant de l’enregistrement de l’espace de noms :

Nom : Société du Chat Botté

Adresse : 1 rue du Chat Botté

Cloville, Seine et Meuse

Contact : L. Daigle

mél : leslie@chatbotte.com


Déclaration de structure : La structure d’identifiant est la suivante :


URN:<numéro alloué>:<FQDN>:<chaîne allouée>


où FQDN est un nom de domaine pleinement qualifié (fully-qualified domain name), et la chaîne allouée est conforme aux exigences de la syntaxe d’URN.


Documentation auxiliaire pertinente :

La définition des noms de domaines, qui se trouve dans P. Mockapetris, "Noms de domaines – mise en œuvre et spécification", RFC 1035, novembre 1987.


Considérations sur l’unicité des identifiants :

L’unicité est garantie tant que la chaîne allouée n’est jamais réallouée pour un FQDN donné, et que le FQDN n’est jamais réalloué.


Note : Du point de vie du fonctionnement, rien n’empêche un nom de domaine d’être réalloué ; bien sûr, ce n’est pas quelque chose de si inhabituel. C’est une des raisons pour lesquelles cet exemple est en pratique un assez mauvais exemple d’espace de noms d’URN, et il n’est donc pas sérieusement proposé tel quel.


Considérations sur la persistance des identifiants :

La persistance des identifiants dépend d’une délégation de résolution convenable au niveau des "FQDN", et de la persistance de l’allocation de FQDN.


Même note que ci-dessus.


Processus de l’allocation d’identifiant :

L’allocation de ces URN est déléguée aux détenteurs de nom de domaine individuel (pour les FQDN). Il est exigé du détenteur de l’enregistrement de FQDN qu’il entretienne une entrée (ou qu’il le délègue) dans le DDDS. Au sein de chacune de ces partitions de nom déléguées, la chaîne peut être allouée selon des exigences locales.

Par exemple, urn:<numéro alloué>:chatbotte.com:001203


Processus de résolution d’identifiant :

Les détenteurs de noms de domaine sont responsables du fonctionnement ou de la délégation du fonctionnement des serveurs de résolution pour le FQDN dans lequel ils ont alloué des URN.


Règles d’équivalence lexicale :

Les FQDN sont insensibles à la casse. Donc, la portion de l’URN urn:<numéro alloué>:<FQDN> est insensible à la casse pour les correspondances. Le reste de l’identifiant doit être considéré comme sensible à la casse.


Conformité à la syntaxe d’URN : Pas de considérations particulières.


Mécanisme de validation : Aucune n’est spécifiée.


Portée : Mondiale.


B.2 Étapes pratiques de l’enregistrement


Les étapes clés de l’enregistrement des espaces de noms informels ou formels se déroulent normalement de la façon suivante :


NID informel :


1. Compléter le gabarit d’enregistrement. Cela peut être fait au titre d’un projet Internet.


2. Communiquer le gabarit d’enregistrement à urn-nid@apps.ietf.org pour l’examen technique – comme projet Internet publié, ou comme message électronique textuel contenant le gabarit.


3. Mettre à jour le gabarit d’enregistrement en tant que de besoin à partir des commentaires, et répéter les étapes 2 et 3 si nécessaire.


4. Une fois que les commentaires ont été traités (et que la période de révision est arrivée à expiration) envoyer une demande à l’IANA avec formulaire d’enregistrement révisé.


NID formel :


1. Rédiger un projet Internet décrivant l’espace de noms et inclure le formulaire d’enregistrement, dûment complété. S’assurer d’avoir inclus les sections "Considérations sur les espaces de noms", "Considérations de communauté" et "Considérations relatives à l’IANA ", comme décrit au paragraphe 4.3.


2. Envoyer le projet Internet à l’éditeur des projets Internet, et envoyer copie à urn-nid@apps.ietf.org pour le relecture technique.


3. Mettre à jour autant que de besoin le projet Internet à partir des commentaires, et répéter les étapes 2 et 3 autant que nécessaire.


4. Envoyer une demande de publication du projet Internet comme RFC à l’IESG. L’IESG peut demander d’autres changements (publiés comme des révisions du projet Internet) et/ou une discussion directe pour désigner des groupes de travail, des experts de domaine, etc.


5. Si l’IESG approuve la publication du document comme RFC, envoyer à l’IANA une demande d’enregistrer le NID demandé.


Appendice C -- Changements par rapport à la RFC2611


La présente révision de la [RFC2611] ajoute des détails qui décrivent le processus d’enregistrement d’identifiant d’un espace de noms d’URN (en termes d’étapes mécaniques).


Cette version du document sépare aussi le traitement (mécanique) de la discussion des exigences pour les espaces de noms, essayant de rendre ces dernières aussi objectives que possible.


Tout au long du document, les références ont été mises à jour avec les versions actuelles du DDDS et avec la documentation qui s’y rapporte (qui rendent collectivement obsolète la [RFC2168] et les projets qui s’y rapportent).


C.1 Changements détaillés du document


Ajout de la table des matière


Section 2

- Précise la définition d’un espace de noms d’URN, de l’unicité d’allocation, et qu’une seule ressource peut avoir plus d’un identifiant associé.

- Précise le "nombre exemple" – que la même chaîne peut apparaître dans deux espaces de noms différents, et être appliqué à des ressources différentes. On utilisait à l’origine l’exemple ISBN/ISSN, mais ce n’est structurellement pas possible.


Section 3 (nouvelle)

Cette section définit explicitement les trois catégories d’espace de noms -- expérimental, informel et formel. Cette section donne une description de l’utilisation prévue pour les différents types d’espace de noms, ainsi que des lignes directrices sur l’acceptabilité des espaces de noms formels (qui exigent l’examen de l’IETF).


Section 4.0

- Développement du titre de la RFC2434 ("Considérations relatives à l’IANA ").

- Donne un pointeur sur le registre d’espace de noms d’URN de l’IANA.


paragraphes 4.1-4.3

Nouvelles divisions des paragraphes de la discussion des types d’espaces de noms individuels.


paragraphe 4.2

Correction des références au document sur la syntaxe des URN (RFC2141, et non la RFC2168).


paragraphe 4.3

- Ajout d’une précision sur la nature prévue des espaces de noms formels et de leur processus d’enregistrement.

- Ajout de la description des exigences pour une section "Considérations sur les espaces de noms" dans les RFC qui définissent des espaces de noms formels. Définition du contenu exigé pour cette section.

- Ajout de la description d’une nouvelle exigence d’une section de "Considérations de communauté" dans les RFC qui définissent des espaces de noms formels. Définition du contenu exigé pour cette section.

- Ajout du texte qui invite explicitement à introduire une section "Considérations relatives à l’IANA" dans de telles RFC, afin d’alerter l’IANA sur l’action requise.

- Ajout d’un texte pour préciser le traitement (par l’IETF) de la révision des enregistrement s d’espace de noms formels par des RFC et la révision par l’IETF.


Section 6

Nouvelle section – ajoute du texte pour décrire les considérations relatives à l’IANA pour ce document.


Section 7 -- Références

Ajout de références à la documentation NAPTR révisé [RFC3401], et à la version précédente de ce document [RFC2611].


Appendice A

- Section créée en déplaçant la section 3 "Gabarit de définition d’espace de noms d’URN" de la RFC2611 dans un appendice.

- Ajout de références aux nouvelles exigences de sections "Considérations d’espace de noms", "Considérations de communauté", et "Considérations relatives à l’IANA" pour les enregistrements d’espaces de noms formels.

- Précision sur l’élément "Dépositaire déclaré de l’espace de noms" du gabarit.

- Ajout de la description de l’objet et de la portée du "mécanisme de validation".


Appendice B

- Le paragraphe B.1 est le "gabarit exemple" qui était la "Section 5" de la RFC2611.

- Mise à jour des données de l’exemple de "dépositaire déclaré" selon les changements de la description du gabarit.

- Suppression de la référence à "US-ASCII" dans la "chaîne spécifique d’espace de noms" de l’exemple.


paragraphe B.2 (nouveau)

Ce nouveau paragraphe est un parcours étape par étape du processus d’enregistrement des espaces de noms informels et formels.


Adresse des auteurs


Leslie L. Daigle

Renato Iannella

Thinking Cat Enterprises

IPR Systems Pty Ltd.

mél : leslie@thinkingcat.com

mél : renato@iprsystems.com


Dirk-Willem van Gulik

Patrik Faltstrom

WebWeaving Internet Engineering

Cisco Systems Inc

Nieuwsteeg 37A

170 W Tasman Drive SJ-13/2

2311 RZ Leiden

San Jose CA 95134

The Netherlands

USA

URL : http://www.webweaving.org/

mél : paf@cisco.com

mél : dirkx@webweaving.org



Déclaration complète de droits de reproduction


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


Ce document et les traductions de celui-ci 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 fourni par la Internet Society.