1. Introduction

Un nom de ressource uniforme (URN) est un identificateur de ressource uniforme (URI) [RFC3986] qui est attribué sous le schéma URI "urn" et un espace de noms URN particulier, avec l'intention que l'URN soit un identificateur de ressource persistant et indépendant de l'emplacement. Un espace de noms URN est un ensemble de tels URN, dont chacun est (1) unique, (2) attribué de manière cohérente et gérée, et (3) attribué selon une définition commune. (Certains espaces de noms URN créent des noms qui n'existent qu'en tant qu'URN, tandis que d'autres attribuent des URN à partir de noms déjà créés dans des systèmes d'identificateurs non-URN, tels que les ISBN [RFC3187], les ISSN [RFC3044] ou les RFC [RFC2648].)

L'attribution des URN est effectuée par une organisation (ou, dans certains cas, selon un algorithme ou un autre processus automatisé) à laquelle un espace de noms URN a été formellement délégué au sein du schéma "urn" (par exemple, un URN dans l'espace de noms URN "example" [RFC6963] pourrait être de la forme "urn:example:foo").

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

1. L'attribution d'un URN est un processus géré.

2. L'espace des espaces de noms URN est lui-même géré.

Alors que d'autres schémas URI peuvent permettre que les identificateurs de ressource soient librement choisis et attribués, tel n'est pas le cas des URN. La correction syntaxique d'un nom commençant par "urn:" ne suffit pas à en faire un URN. Pour que le nom soit un URN valide, l'identificateur d'espace de noms (NID) doit être enregistré conformément aux règles définies ici, et les parties restantes de la portion assigned-name de l'URN doivent être générées conformément aux règles de l'espace de noms URN enregistré.

Afin que les informations sur la syntaxe URN et sur les espaces de noms URN soient disponibles en un seul endroit, le présent document effectue ce qui suit :

1. Il définit la syntaxe canonique des URN en général (d'une manière cohérente avec la syntaxe URI), spécifie des méthodes pour déterminer l'URN-equivalence et traite de la conformité URI.

2. Il spécifie une méthode pour définir un espace de noms URN et l'associer à un NID particulier, et décrit les procédures d'enregistrement des NID d'URN auprès de l'Internet Assigned Numbers Authority (IANA).

En ce qui concerne la syntaxe URN et les espaces de noms URN, le présent document modernise et remplace les spécifications d'origine de la syntaxe URN [RFC2141] et de la définition et de l'enregistrement des espaces de noms URN [RFC3406]. Ces modifications s'appuient sur les exigences clés fournies dans la description fonctionnelle d'origine des URN [RFC1737] et sur les enseignements de nombreuses années d'expérience. Dans ces documents d'origine comme dans le présent document, l'intention est de définir les URN de manière cohérente afin que, partout où cela est pratique, l'analyse syntaxique, le traitement et la résolution des URN puissent être indépendants de l'espace de noms URN dans lequel un URN donné est attribué.

Compte tenu également des contributions de plusieurs communautés d'utilisateurs clés, l'histoire et l'expérience des URN ont dicté l'extension de la définition des URN afin de prendre en charge de nouvelles fonctionnalités, y compris l'utilisation d'une syntaxe explicitement réservée à une normalisation future dans la RFC 2141. Tous les espaces de noms URN et tous les URN qui étaient valides selon les spécifications antérieures le restent, même s'il peut être utile de mettre à jour les définitions de certains espaces de noms URN pour tirer parti des nouvelles fonctionnalités.

Les considérations qui précèdent, ainsi que diverses différences entre les URN et les URI qui sont des localisateurs (en particulier les URL), de même que l'accent plus marqué mis sur les URL dans la RFC 3986 en tant que successeur ultime de [RFC1738] et [RFC1808], peuvent conduire à certaines interprétations de la RFC 3986 et de la présente spécification qui apparaissent (ou sont peut-être réellement) pas totalement cohérentes, en particulier en ce qui concerne les actions ou les sémantiques autres que la syntaxe de base elle-même. Si de telles situations se présentent, les discussions sur les URN et les espaces de noms URN doivent être interprétées selon le présent document et non par extrapolation à partir de la RFC 3986.

Des résumés des changements par rapport aux RFC 2141 et 3406 figurent respectivement dans les annexes B et C. Le présent document rend obsolètes à la fois [RFC2141] et [RFC3406]. Bien qu'il ne mette pas explicitement à jour ni ne remplace [RFC1737] ou [RFC2276], le lecteur qui se réfère à ces documents doit être conscient que le modèle conceptuel des URN dans le présent document diffère légèrement de celui de ces spécifications plus anciennes.

1.1. Terminologie

Les termes suivants se distinguent les uns des autres comme décrit ci-dessous :

URN : Un URI (tel que défini dans la RFC 3986) utilisant le schéma "urn" et présentant les propriétés d'un "nom" telles que décrites dans ce document, ainsi que les propriétés décrites dans le présent document. Le terme s'applique à l'URI entier, y compris ses composants facultatifs. Note au lecteur : le terme "URN" a été utilisé dans d'autres contextes pour désigner un espace de noms URN, l'identificateur d'espace de noms, le assigned-name, et des URI qui n'utilisent pas le schéma "urn". Tous ces emplois, sauf le dernier, sont décrits à l'aide d'une terminologie plus précise ailleurs dans le présent document, mais, en raison de ces autres usages, le terme doit être utilisé et interprété avec prudence.

Localisateur : Un identificateur qui fournit un moyen d'accéder à une ressource.

Système d'identificateurs : Un ensemble géré de noms. Le présent document désigne les systèmes d'identificateurs extérieurs au contexte des URN comme des "systèmes d'identificateurs non-URN".

Espace de noms URN : Un système d'identificateurs associé à un NID d'URN.

NID : L'identificateur associé à un espace de noms URN.

NSS : La partie d'un URN propre à l'espace de noms URN.

Assigned-name : La combinaison du schéma "urn:", du NID et de la chaîne spécifique à l'espace de noms (NSS). Un "assigned-name" est par conséquent une sous-chaîne d'un URN (tel que défini ci-dessus) si cet URN contient des composants supplémentaires (voir la section 2).

Le terme "nom" n'est délibérément pas défini ici et devrait être (et, en pratique, est) utilisé de manière très informelle uniquement. La RFC 3986 utilise le terme comme une catégorie d'URI distinguée de "localisateur" (section 1.1.3), mais l'utilise aussi dans d'autres contextes. Si ces usages étaient traités comme définitoires, ils entreraient en conflit avec, par exemple, l'idée de noms d'espaces de noms URN (c'est-à-dire les NID) et avec les termes associés aux systèmes d'identificateurs non-URN.

Le présent document utilise les termes "ressource", "identificateur", "identifier", "déréférencer", "représentation" et "métadonnées" à peu près tels qu'ils sont définis dans la spécification URI [RFC3986].

Le présent document utilise les termes "résolution" et "résolveur" à peu près dans le sens où ils étaient employés dans la discussion d'origine sur les principes architecturaux des URN [RFC2276], c'est-à-dire que la "résolution" est l'acte consistant à fournir des services liés à la ressource identifiée, tels que la traduction de l'URN persistant en un ou plusieurs localisateurs courants de la ressource, la livraison de métadonnées sur la ressource dans un format approprié, ou même la livraison d'une représentation de la ressource (par exemple, un document) sans exiger d'intermédiaires supplémentaires. Au moment de la rédaction du présent document, les services de résolution sont décrits dans [RFC2483].

Sur la distinction entre représentations et métadonnées, voir la section 1.2.2 de [RFC3986].

Plusieurs autres termes liés aux opérations de "normalisation" qui ne font pas partie de la norme Unicode [UNICODE] sont également utilisés ici comme ils le sont dans la RFC 3986.

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" du présent document doivent être interprétés comme décrit dans [RFC2119].

1.2. Compromis de conception

Dans une mesure bien plus grande que lorsque les URN ont été envisagés pour la première fois et que leurs usages ont été esquissés (voir [RFC1737]), les questions d'identificateurs persistants sur l'Internet impliquent des compromis de conception fondamentaux qui sont bien plus larges que les URN ou l'approche URN et touchent même à des questions de recherche ouvertes au sein de la communauté des sciences de l'information. Des spécifications idéales et exhaustives sur ce qui devrait être fait ou exigé dans tout l'univers des URN exigeraient un accord général sur un large éventail de telles questions, ainsi que des solutions à celles-ci. Bien que certaines de ces questions aient été introduites par les approches de l'Internet ou de l'ère informatique en matière d'encodages de caractères et d'abstraction des données, d'autres précèdent l'Internet et les systèmes informatiques de plusieurs siècles ; il est peu probable qu'un accord sur des solutions exhaustives se dégage dans un avenir proche.

Bien que la présente spécification contienne par conséquent certaines exigences et une certaine souplesse qui ne seraient pas présentes dans un monde plus parfait, cela a été nécessaire afin de produire une spécification consensuelle qui fournisse une définition modernisée des URN (l'alternative peu attrayante aurait été de ne pas moderniser la définition malgré un déploiement très répandu).

Les sous-sections suivantes décrivent plus en détail deux des questions pertinentes.

1.2.1. Résolution

Une question propre aux URN (par opposition aux systèmes de nommage en général) est le sujet assez difficile de la "résolution", discuté dans les sections 1.1, 2.3.1, 6.4.6 et ailleurs ci-dessous.

Avec les localisateurs de ressources uniformes (URL) traditionnels, c'est-à-dire avec la plupart des URI qui sont des localisateurs, la résolution est relativement simple, car elle sert à déterminer un mécanisme d'accès qui est ensuite utilisé pour déréférencer le localisateur en récupérant (généralement) une représentation de la ressource associée, telle qu'un document (voir la section 1.2.2 de [RFC3986]).

En revanche, la résolution des URN est plus souple et plus variée.

Un cas important concerne la mise en correspondance d'un URN avec un ou plusieurs localisateurs. Dans ce cas, le résultat final reste une question de déréférencement du ou des localisateurs mis en correspondance vers une ou plusieurs représentations. La principale différence ici est la persistance : même si un localisateur mis en correspondance a changé (par exemple, un nom de domaine DNS a changé de titulaire et une URL n'a pas été modifiée pour pointer vers un nouvel emplacement ou, dans un cas plus extrême et hypothétique, le DNS est entièrement remplacé), un utilisateur d'URN pourra obtenir la représentation correcte (par exemple, un document) tant que le résolveur a tenu à jour ses correspondances URN-vers-localisateur. Par conséquent, les relations pertinentes peuvent être définies de manière assez précise pour les URN qui se résolvent en localisateurs eux-mêmes déréférencés vers une représentation.

Toutefois, la présente spécification autorise également plusieurs autres cas de résolution d'URN, ainsi que des URN pour des ressources qui n'impliquent pas de systèmes de recherche d'informations. Cela vaut soit individuellement pour des URN particuliers, soit (comme défini ci-dessous) collectivement pour des espaces de noms URN entiers.

Considérons un espace de noms d'URN qui se résolvent en localisateurs eux-mêmes déréférencés uniquement vers des métadonnées concernant des ressources, parce que les systèmes sous-jacents ne contiennent aucune représentation de ces ressources ; un exemple pourrait être un espace de noms URN pour les International Standard Name Identifiers (ISNI) tels que ce système d'identificateurs est défini dans la norme pertinente [ISO.27729.2012], dans lequel, par défaut, un URN ne serait résolu que vers un enregistrement de métadonnées décrivant l'identité publique identifiée par l'ISNI.

Considérons aussi des URN qui ne se résolvent vers des représentations que si l'entité demandeuse est autorisée à obtenir la représentation, tandis que d'autres entités ne peuvent obtenir que des métadonnées sur la ressource ; un exemple pourrait être des documents conservés dans la collection du dépôt légal d'une bibliothèque nationale.

Enfin, certains URN peuvent ne pas être destinés à se résoudre du tout vers des localisateurs ; les exemples peuvent inclure des URN identifiant des noms d'espaces de noms XML (par exemple, l'espace de noms URN "dgiwg" spécifié par [RFC6288]), des URN identifiant des fonctionnalités d'application pouvant être prises en charge dans un protocole de communication (par exemple, l'espace de noms URN "alert" spécifié par [RFC7462]), et des URN identifiant des types énumérés tels que des valeurs dans un registre (par exemple, un espace de noms URN pourrait servir à identifier individuellement les valeurs de tous les registres de l'IANA, comme provisoirement proposé dans [IANA-URN]).

Les divers types d'URN et les multiples services de résolution qui peuvent être disponibles pour eux rendent le concept de "résolution" plus compliqué, mais aussi beaucoup plus riche pour les URN que le cas simple d'une résolution vers un localisateur déréférencé vers une représentation.

1.2.2. Jeux de caractères et encodages

Un ensemble similaire de considérations s'applique aux jeux de caractères et aux encodages. Les URN, en particulier les URN qui seront utilisés comme identificateurs destinés aux utilisateurs, devraient être pratiques à utiliser dans les langues et les systèmes d'écriture locaux, faciles à saisir avec un large éventail de claviers et de conventions locales, et non ambigus. Il existe des compromis entre ces objectifs, et il est actuellement impossible de voir comment un ensemble de règles simple et aisément compréhensible pourrait être élaboré qui serait optimal, ou même raisonnable, pour tous les URN. La discussion de la section 2.2 définit un cadre général qui devrait rendre possible une analyse syntaxique et un traitement généralisés, mais formule aussi des recommandations sur les règles propres à chaque espace de noms URN.