Adresses URI, URL et URN : Clarifications et recommandations 1.0

1 Le partitionnement URI

Il existe une certaine confusion dans la communauté Web concernant le partitionnement de l'espace URI, notamment les relations entre les concepts URL, URN et URI. La confusion est due à l'incompatibilité entre deux visions différentes du partitionnement URI, que nous qualifierons de vision « classique » et de vision « contemporaine ».

1.1 La vision classique

Durant les premières années de la discussion à propos des identificateurs Web (du début au milieu des années 90), on supposait qu'un type d'identificateur serait rangé dans une ou deux classes (voire plus). Un identificateur définissait l'emplacement d'une ressource (une adresse URL) ou son nom (une adresse URN) indépendant de l'emplacement. Une adresse URI était donc soit une adresse URL, soit une adresse URN. Il était question de généraliser cette définition en ajoutant un nombre discret de classes supplémentaires ; par exemple, une adresse URI pourrait pointer vers des métadonnées plutôt que sur la ressource même, auquel cas l'adresse URI serait une adresse URC (une citation). En conséquence, l'espace URI était vu comme partitionné en sous-espaces : URL et URN, et des sous-espaces supplémentaires à définir. Le seul espace de ce type jamais proposé fut URC qui n'emporta jamais aucune adhésion ; de fait, pour rester général, il est raisonnable de dire qu'on pensait l'espace URI partitionné en deux classes : URL et URN. Ainsi, par exemple, « http: » était un schéma URL et « isbn: » serait (un de ces jours) un schéma URN. Tout nouveau schéma se rangerait dans l'une ou l'autre classes.

1.2 La vision contemporaine

Avec le temps, l'importance de cette hiérarchisation supplémentaire semblait diminuer ; la vision devint celle selon laquelle un schéma individuel n'a pas besoin d'être enfermé dans un ensemble discret de types URI tels que « URL », « URN », « URC », etc. Les schémas d'identificateurs Web sont en général des schémas URI ; un schéma URI donné peut définir des sous-espaces. Ainsi, « http: » est un schéma URI. Et « urn: » est aussi un schéma URI ; il définit des sous-espaces, appelés « espaces de noms ». Par exemple, l'ensemble des adresses URN de la forme "urn:isbn:n-nn-nnnnnn-n" est un espace de noms URN. (« isbn » est un identificateur d'espace de noms URN. Ce n'est pas un « schéma URN » ni un « schéma URI »).

En outre, dans la vision contemporaine, le terme « URL » ne désigne pas une partition formelle de l'espace URI ; au lieu de ça, URL est un concept utile mais informel : une adresse URL est un type d'adresse URI qui identifie une ressource via une représentation de son mécanisme d'accès primaire (par exemple, son « emplacement » de réseau) plutôt que par d'autres attributs qu'elle peut avoir. Ainsi que nous l'avons remarqué, "http:" est un schéma URI. Une adresse URI http est une adresse URL. L'expression « schéma URL » est peu utilisée actuellement, habituellement pour désigner des sous-classes de schémas URI qui excluent les adresses URN.

1.3 La confusion

Le corps de documents (RFC, etc.) régissant l'architecture, la syntaxe, l'enregistrement URI, etc. recouvre à la fois la période classique et la période contemporaine. Les personnes versées dans les questions d'URI ont apparemment tendance à utiliser « URL » et « URI » de façon interchangeable. Dans ce milieu d'experts, ce n'est pas un problème. Mais dans la communauté Internet au sens large, ça l'est. Les gens ne sont pas convaincus qu'« URI » et « URL » signifient la même chose dans les documents où c'est (manifestement) le cas. Lorsqu'on voit un document RFC discutant de schémas URI (par exemple [RFC 2396]), un autre discutant de schémas URL (par exemple, [RFC 2717]), et un autre encore de schémas URN ([RFC 2276]), il est naturel de se demander ce qui les différencie et en quoi ils sont liés. Bien que le document RFC 2396 1.2 tente d'expliquer la distinction entre adresses URI, URL et URN, il ne réussit pas à dissiper la confusion.

2 L'enregistrement

Cette section examine l'état d'enregistrement des schémas URI et des espaces de noms URN, et les mécanismes d'enregistrement actuels.

2.1 Les schémas URI

2.1.1 Les schémas URI enregistrés

Le registre officiel des noms de schémas URI est tenu par l'IANA, à http://www.iana.org/assignments/uri-schemes. Le document RFC qui définit chaque schéma y est listé, par exemple, "http:" est définit par [RFC 2616]. Le tableau contient actuellement 30 schémas. En outre, il y a quelques noms de schémas « réservés » ; à un moment donné, ceux-ci devaient devenir des schémas enregistrés mais ils ont été abandonnés depuis.

2.1.2 Les schémas URI non enregistrés

Nous distinguons les schémas publics (non enregistrés) des schémas privés. Un schéma public (enregistré ou non) est un schéma décrit par un document public.

2.1.2.1 Les schémas publics non enregistrés

Dan Connolly tient une liste de schémas URI publics, enregistrés ou non, totalisant 84 schémas. Il y en a environ 50 qui ne sont pas enregistrés (non listés dans le registre de l'IANA). Certains sont obsolètes (par exemple, c'est le cas de « phone », remplacé par « tel »). Certains ont un RFC mais ne sont pas compris dans la liste de l'IANA.

2.1.2.2 Les schémas privés

Il est probablement impossible de tous les déterminer, et il n'est pas sûr que cela en vaille la peine, sauf peut-être pour avoir une idée de leur nombre. Les minutes de la réunion de l'IETF d'août 1997 en observaient 20-40 en usage chez Microsoft, dont 2-3 ajoutés chaque jour, et WebTV en avait 24, 6 s'y ajoutant chaque année.

2.1.3 L'enregistrement des schémas URI

Le document [RFC 2717] définit les procédures d'enregistrement des noms de schémas, et dirige vers le document [RFC 2718] qui fournit des directives. Le document RFC 2717 décrit une organisation de schémas sous forme d'« arbres ».

2.1.3.1 L'arbre IETF

L'arbre IETF est destiné aux schémas d'intérêt général pour la communauté Internet, et il nécessite un processus d'examen et d'approbation important. L'enregistrement dans l'arbre IETF impose la publication de la syntaxe et de la sémantique du schéma dans un document RFC.

2.1.3.2 Les autres arbres

Bien que le document RFC 2717 décrive d'« autres arbres », aucun n'a été enregistré à ce jour, quoiqu'il y ait en attente un arbre fourni par les vendeurs (« vnd »). Les schémas URI des autres arbres seront distingués par un point « . » dans le nom du schéma.

2.2 Les espaces de noms URN

Un espace de noms URN est identifié par un identificateur d'espace de noms (N.d.T. Namespace ID, ou NID), enregistré auprès de l'IANA (cf. « 2.2.4 Les procédures d'enregistrement des identificateurs d'espaces de noms URN »).

2.2.1 Les identificateurs d'espaces de noms URN enregistrés

Il y a deux catégories d'identificateurs d'espaces de noms URN enregistrés :

Informels : ils sont de la forme « urn-<numéro> », où <numéro> est assigné par l'IANA. Il y en a trois enregistrés dans cette catégorie (« urn-1 », « urn-2 » et « urn-3 »).
Formels : La liste officielle des identificateurs d'espaces de noms enregistrés est tenue par l'IANA à http://www.iana.org/assignments/urn-namespaces. Elle contient actuellement 8 identificateurs d'espaces de noms enregistrés :

ietf

défini par [RFC 2648] « Un espace de noms URN pour les documents IETF »

pin

défini par [RFC 3043] « Le nom Internet personnel (PIN) de Network Solutions : Un espace de noms URN pour les personnes et les organisations »

issn

défini par [RFC 3044] « Utiliser le numéro ISSN comme adresse URN au sein d'un espace de noms ISSN-URN »

oid

défini par [RFC 3061], « Un espace de noms URN pour les identificateurs d'objets »

newsml

défini par [RFC 3085] « Un espace de noms URN pour les ressources NewsML »

oasis

défini par [RFC 3121] « Un espace de noms URN pour OASIS »

xmlorg

défini par [RFC 3120] « Un espace de noms URN pour XML.org »

publicid

défini par [RFC 3151] « Un espace de noms URN pour les identificateurs publics »

2.2.2 Les identificateurs d'espaces de noms URN en attente

Il y a, en attente, plusieurs demandes d'enregistrement d'identificateurs d'espaces de noms URN, mais il n'existe aucun moyen fiable de les découvrir ou de connaître leur statut. Par exemple, « isbn » et « nbn » ont été approuvés par l'IESG et sont dans la file d'attente des rédacteurs de RFC. Notamment, « isbn », comme espace de noms URN potentiel (ou schéma URI), a été à l'origine de beaucoup de spéculations et de confusion plusieurs années durant. Il serait utile qu'il exite un moyen formel de tracer le statut des demandes d'identificateurs d'espaces de noms tel « isbn ».

2.2.3 Les identificateurs d'espaces de noms non enregistrés

Dans la catégorie « non enregistré » (hormis le cas expérimental, non décrit dans ce document), il y a des identificateurs d'espaces de noms valables qui n'ont pas même daigné emprunter le processus d'enregistrement. Celui qui vient d'abord à l'esprit est « hdl ». Dans le cas de « hdl », on avait spéculé que ce schéma n'avait pas été enregistré parce qu'il n'était pas clair pour son propriétaire s'il fallait l'enregistrer en tant que schéma URI ou bien qu'espace de noms URN.

2.2.4 Les procédures d'enregistrements des identificateurs d'espaces de noms URN

Le document [RFC 2611] décrit la démarche pour obtenir un identificateur d'espace de noms URN, qui est faite auprès de l'IANA.

Une demande d'identificateur d'espace de noms devrait comporter des descriptions telles que : une caractéristique structurelle de l'identificateur (par exemple, les aspects relatifs aux approches de mise en cache/raccourcis), des règles spécifiques de codage des caractères (par exemple, quel caractère utiliser pour les guillemets simples), des documents RFC, des standards, etc. qui expliquent la structure de l'espace de noms, une réflexion autour de l'unicité de l'identificateur, une délégation de l'autorité d'assignation, y compris comment devenir un assignataire des identificateurs, une réflexion autour de la persistence de l'identificateur, une réflexion autour de la qualité de service, un processus de résolution de l'identificateur, des règles d'équivalence lexicale, toutes considérations spéciales nécessaires pour la conformité avec la syntaxe URN (tout particulièrement en présence de systèmes de nommage existants), des mécanismes de validation (déterminant si une chaîne données est actuellement un espace de noms URN légalement assigné et une portée (par exemple, « Numéros de sécurité sociale des États-Unis »).

3 Les autres problèmes d'URI

Concernant les adresses URI, il y a d'autres problèmes non résolus, non abordés par cette note, auxquels nous espérons apporter des réponses dans des travaux à suivre. Nous n'avons pas essayé de tous les énumerer, toutefois, en voici quelques uns :

L'utilisation d'adresses URI comme identificateurs qui n'identifient pas réellement de ressources en réseau (par exemple, ils identifient un objet abstrait tel qu'un schéma XML, ou un objet physique tel qu'un livre ou une personne) ;
Les adresses IRI (International Resource Identifier) : l'extension de la syntaxe URI aux codes non-ASCII.

4 Les recommandations

Nous recommandons ce qui suit :

Le W3C et l'IETF devraient développer et endosser conjointement un modèle d'adresses URI, URL et URN conforme à la « vision contemporaine » décrite dans la section n° 1, et qui tienne compte des problèmes d'adresse URI supplémentaires listés ou auxquels il a été fait allusion dans la section n° 3 ;
Les documents RFC tels le RFC 2717 (« Procédures d'enregistrement des noms de schémas URL ») et le RFC 2718 (« Directives pour les nouveaux schémas URL ») devraient être généralisés comme se rapportant aux « schémas URI » au lieu des « schémas URL » et, après affinage, être avancés comme meilleure pratique actuelle au sein de l'IETF ;
Les procédures d'enregistrement des autres arbres devraient être clarifiées dans le document RFC 2717 ;
Les schémas publics mais pas enregistrés devraient l'être quand c'est possible. Les schémas obsolètes devraient être purgés ou clairement repérés comme tels ;
Les enregistrements de l'IANA devraient être mis à jour :
- Ajouter « urn » à la liste des schémas URI enregistrés avec un pointeur sur le registre de l'espace de noms URN ;
- Tenir un état des enregistrements en attente (schémas URI et demandes d'identificateurs d'espaces de noms URN) ;
- Montrer clairement qu'il s'agit de la page du registre officiel, par exemple, en ajoutant effectivement un titre « Voici le registre IANA officiel des schémas URI ».