Aller au contenu principal

4. Conformité URI

4.1. Utilisation dans les emplacements de protocole d'URI​

Parce qu'un URN est, sur le plan syntaxique, un URI relevant du schéma "urn", un URN peut en théorie être placé dans tout emplacement de protocole qui accepte un URI (pour n'en citer que quelques-uns : les attributs "href" et "src" en HTML, l'élément base en HTML, l'attribut "xml:base" en XML [XML-BASE] et l'attribut "xmlns" en XML pour les noms d'espaces de noms XML [XML-NAMES]).

Toutefois, cela n'implique pas que, sur le plan sémantique, il soit toujours judicieux en pratique de placer un URN dans un emplacement de protocole d'URI donné ; en particulier, parce qu'un URN peut ne pas spécifier l'emplacement d'une ressource ou même ne pas pointer indirectement vers une ressource, il peut être inapproprié de placer un URN dans un emplacement de protocole d'URI qui pointe vers une ressource (par exemple, les attributs "href" et "src" susmentionnés).

En dernière analyse, les lignes directrices concernant le moment où il est approprié d'utiliser des URI relevant du schéma "urn" (ou de tout autre schéma) relèvent de la responsabilité des spécifications des emplacements de protocole d'URI individuels (par exemple, la spécification de l'attribut "xml:base" en XML pourrait recommander qu'il soit inapproprié d'utiliser des URN dans cet emplacement de protocole). La présente spécification ne peut pas anticiper tous les cas pertinents, et il n'appartient pas à cette spécification d'exiger ou de restreindre l'usage pour des emplacements de protocole individuels.

4.2. Analyse syntaxique​

En partie en raison de la séparation entre la sémantique des URN et la syntaxe URI plus générale, les processeurs d'URI génériques doivent accorder une attention particulière aux règles d'analyse syntaxique et d'analyse sémantique de la RFC 3986 et, en particulier, doivent traiter l'URI comme opaque, sauf si le schéma et ses exigences sont reconnus. Dans ce dernier cas, de tels processeurs peuvent être en mesure de déclencher un traitement approprié au schéma, par exemple par un résolveur d'URN. Un résolveur d'URN peut être soit un résolveur externe que le résolveur d'URI connaît, soit une fonctionnalité intégrée au résolveur d'URI. Notez que cette exigence peut imposer des contraintes sur les contextes dans lesquels les URN sont utilisés de manière appropriée ; voir la section 4.1.

4.3. URN et références relatives​

La section 5.2 de [RFC3986] décrit un algorithme permettant de convertir une référence d'URI qui peut être relative à un URI de base donné en "composants analysés" de la cible de cette référence, lesquels peuvent ensuite être recomposés conformément à la section 5.3 de la RFC 3986 en un URI cible. Cet algorithme pose problème pour les URN, car leur syntaxe ne prend pas en charge les composants de chemin nécessaires. Toutefois, si l'algorithme est appliqué indépendamment d'un schéma particulier, il devrait fonctionner de manière prévisible pour les URN également, avec les précisions suivantes (la terminologie des productions syntaxiques est reprise de la RFC 3986) :

  1. Un système qui rencontre une <URI-reference> obéissant à la syntaxe de <relative-ref>, qu'elle ait ou non explicitement le schéma "urn", la convertira en un URI cible comme spécifié dans la RFC 3986.

  2. En raison des attentes de persistance et de stabilité des URN, les auteurs de documents, etc., qui utilisent des URN devraient généralement éviter l'emploi du schéma "urn" dans toute <URI-reference> qui n'est pas strictement une <URI> telle que spécifiée dans la RFC 3986, y compris en particulier celles qui exigeraient un traitement de <relative-ref>.

4.4. Transport et affichage​

Lorsque des URN sont transportés et échangés, ils doivent être représentés dans le format défini dans le présent document (MUST). En outre, il est vivement encouragé que les applications conscientes des URN offrent la possibilité d'afficher les URN sous cette forme canonique afin de permettre une transcription directe (par exemple au moyen de techniques de copier-coller). De telles applications pourraient prendre en charge l'affichage des URN sous une forme plus conviviale et pourraient utiliser un jeu de caractères comprenant des caractères non autorisés par la syntaxe URN telle que définie dans la présente spécification (par exemple, lors de l'affichage d'URN à des humains, de telles applications pourraient remplacer les chaînes encodées en pourcentage par des caractères issus d'un répertoire de caractères étendu tel qu'Unicode [UNICODE]).

Afin de minimiser la confusion des utilisateurs, toute application affichant des URI devrait afficher l'URI complet (y compris, pour les URN, le schéma "urn" et tout composant) afin de garantir qu'il n'y ait aucune confusion entre les NID d'URN et les identificateurs de schéma d'URI (SHOULD). Par exemple, un URI commençant par "urn:xmpp:" [RFC4854] est très différent d'un URI commençant par "xmpp:" [RFC5122]. De même, un éventuel schéma d'URI Digital Object Identifier (DOI) [DOI-URI] est différent d'un éventuel espace de noms URN DOI, et peut-être totalement sans rapport avec lui.

4.5. Conception et propriété des URI​

Comme mentionné, l'attribution des URN au sein d'un espace de noms URN est un processus géré, tout comme l'attribution des espaces de noms URN eux-mêmes. Bien que la conception des URN à attribuer au sein d'un espace de noms URN donné soit cédée par la présente spécification au gestionnaire de l'espace de noms URN, le faire d'une manière gérée évite les problèmes inhérents à la génération non gérée d'URI, tels que décrits dans les recommandations relatives à la conception et à la propriété des URI [RFC7320].