Aller au contenu principal

2. Syntaxe des URN

Comme discuté ci-dessus, la syntaxe des URN dans la présente spécification permet une fonctionnalité nettement plus étendue que ce n'était le cas dans les spécifications antérieures, la plus récente étant [RFC2141]. Elle est également harmonisée avec la syntaxe URI générale [RFC3986] (laquelle, il faut le noter, a été achevée après les spécifications URN antérieures).

Toutefois, la présente spécification n'étend pas la syntaxe URN pour permettre l'utilisation directe de caractères hors de la plage ASCII [RFC20]. Cette restriction implique que de tels caractères doivent être encodés en pourcentage comme décrit à la section 2.1 de la spécification URI [RFC3986].

La syntaxe de base d'un URN est définie à l'aide de la forme augmentée de Backus-Naur (ABNF) telle que spécifiée dans [RFC5234]. Les règles non définies ici (à savoir : alphanum, fragment et pchar) sont définies dans le cadre de la syntaxe URI [RFC3986] et sont utilisées ici pour souligner la relation syntaxique avec les termes qui y sont employés. Les définitions de certains des termes utilisés ci-dessous ne sont pas exhaustives ; des restrictions supplémentaires sont imposées par le texte explicatif que l'on trouve dans les sections du présent document propres à ces termes (en particulier r-component à la section 2.3.1 et q-component à la section 2.3.2).

namestring    = assigned-name
                [ rq-components ]
                [ "#" f-component ]
assigned-name = "urn" ":" NID ":" NSS
NID           = (alphanum) 0*30(ldh) (alphanum)
ldh           = alphanum / "-"
NSS           = pchar *(pchar / "/")
rq-components = [ "?+" r-component ]
                [ "?=" q-component ]
r-component   = pchar *( pchar / "/" / "?" )
q-component   = pchar *( pchar / "/" / "?" )
f-component   = fragment

Le caractère point d'interrogation "?" peut être utilisé sans encodage en pourcentage à l'intérieur des r-component, q-component et f-component. En dehors de ces composants, un "?" qui n'est pas immédiatement suivi de "=" ou de "+" n'est pas défini pour les URN et devrait être traité comme une erreur de syntaxe par les analyseurs syntaxiques propres aux URN et les autres processeurs (SHOULD).

Les sections suivantes fournissent des informations supplémentaires sur les éléments syntaxiques des URN.

2.1. Identificateur d'espace de noms (NID)​

Les NID sont insensibles à la casse (par exemple, "ISBN" et "isbn" sont équivalents).

Les caractères hors de la plage ASCII [RFC20] ne sont pas autorisés dans les NID, et aucun mécanisme d'encodage de tels caractères n'est pris en charge.

Les sections 5.1 et 5.2 imposent des contraintes supplémentaires sur les chaînes pouvant servir de NID, c'est-à-dire que la syntaxe présentée ci-dessus n'est pas exhaustive.

2.2. Chaîne spécifique à l'espace de noms (NSS)​

Le NSS est une chaîne, unique au sein d'un espace de noms URN, qui est attribuée et gérée de manière cohérente et qui est conforme à la définition de l'espace de noms URN concerné. La combinaison du NID (unique dans tout le schéma "urn") et du NSS (unique au sein de l'espace de noms URN) garantit que l'URN résultant est globalement unique.

Le NSS tel que spécifié dans le présent document autorise plusieurs caractères non permis par les spécifications antérieures (voir l'annexe B). En particulier, le caractère "/", désormais autorisé, rend effectivement possible l'encapsulation de noms hiérarchiques issus de systèmes d'identificateurs non-URN. Par exemple, considérons l'exemple hypothétique d'un système d'identificateurs hiérarchique dans lequel les noms prennent la forme d'une séquence de nombres séparés par le caractère "/", telle que "1/406/47452/2". Si l'autorité responsable de tels noms utilisait des URN, il serait naturel de placer le nom existant dans le NSS, ce qui donnerait des URN tels que "urn:example:1/406/47452/2".

Ces modifications de la syntaxe du NSS ne modifient pas les règles d'encodage des espaces de noms URN qui ont été définis conformément à [RFC2141]. Si un tel espace de noms URN dont les noms sont utilisés en dehors du contexte URN (c'est-à-dire dans un système d'identificateurs non-URN) autorise également l'utilisation de "/", "~" ou "&" sous la forme native au sein de ce système d'identificateurs, alors les règles d'encodage de cet espace de noms URN ne sont pas modifiées par la présente spécification.

Selon les règles régissant un système d'identificateurs non-URN et l'espace de noms URN qui lui est associé, des noms valides dans ce système d'identificateurs peuvent contenir des caractères non autorisés par la production "pchar" référencée ci-dessus (par exemple, des caractères hors de la plage ASCII ou, conformément aux restrictions de la RFC 3986, les caractères "/", "?", "#", "[" et "]"). Bien qu'un tel nom puisse être valide au sein du système d'identificateurs non-URN, il n'est pas un URN valide tant qu'il n'a pas été traduit en un NSS conforme aux règles de cet espace de noms URN particulier. Dans le cas des URN formés à partir de noms qui existent séparément dans un système d'identificateurs non-URN, la traduction d'un nom de son format "natif" vers un format URN s'accomplit en utilisant les méthodes de canonisation et d'encodage définies pour les URN en général ou les règles propres à cet espace de noms URN. Les logiciels qui ne connaissent pas les règles de canonisation et d'encodage propres à un espace de noms ne doivent pas construire d'URN à partir du nom du système d'identificateurs non-URN (MUST NOT).

En particulier, en ce qui concerne les caractères hors de la plage ASCII, les URN qui apparaissent dans des protocoles ou qui sont transmis entre systèmes doivent utiliser uniquement des caractères Unicode encodés en UTF-8 puis encodés en outre comme l'exige la RFC 3986 (MUST). Dans la mesure du possible et de manière compatible avec les exigences des noms définis et normalisés ailleurs, ainsi qu'avec les principes discutés à la section 1.2, les caractères utilisés pour représenter les noms devraient être limités soit à des lettres et chiffres ASCII, soit aux caractères et à la syntaxe de certains modèles largement utilisés tels que ceux de l'internationalisation des noms de domaine dans les applications (IDNA) [RFC5890], de la préparation, de l'application et de la comparaison de chaînes internationalisées (PRECIS) [RFC7613], ou de la spécification Unicode Identifier and Pattern Syntax [UAX31] (SHOULD).

Afin de rendre les URN aussi stables et persistants que possible lorsque les protocoles évoluent et que leur environnement change, les espaces de noms URN ne devraient pas autoriser de caractères hors de la plage ASCII [RFC20], sauf si la nature de l'espace de noms URN particulier rend ces caractères nécessaires (SHOULD NOT).

2.3. Composants facultatifs​

La présente spécification inclut trois composants facultatifs dans la syntaxe URN. Ils sont appelés r-component, q-component et f-component et sont décrits plus en détail ci-dessous. Comme la présente spécification se concentre presque exclusivement sur la syntaxe URN, elle ne définit pas la sémantique détaillée de ces composants pour les URN en général. Toutefois, chacun de ces composants a un rôle distinct qui est indépendant de tout URN donné et de son espace de noms URN. Il est prévu que les clients puissent traiter ces composants de manière uniforme pour tous les URN. Ces composants peuvent être utilisés avec des URN issus d'espaces de noms URN existants, que cet espace de noms URN les prenne explicitement en charge ou non (MAY). Toutefois, conformément à l'approche adoptée dans la RFC 3986, le comportement d'un URN contenant des composants qui sont indéfinis ou dépourvus de sens pour un espace de noms URN ou une ressource particuliers n'est pas défini. Les sections suivantes décrivent ces composants facultatifs et leur interprétation plus en détail.

2.3.1. r-component​

Le r-component est destiné à transmettre des paramètres aux services de résolution d'URN (au sens large, voir la section 1.2) et à être interprété par ces services. (En revanche, la transmission de paramètres aux ressources identifiées par un URN, ou aux applications qui gèrent ces ressources, est traitée par les q-component comme décrit dans la section suivante.)

Le r-component d'URN n'a pas d'équivalent syntaxique dans aucun autre schéma URI connu.

La séquence "?+" introduit le r-component. Le r-component se termine par une séquence "?=" (qui commence un q-component) ou par un caractère "#" (dièse, qui commence un f-component). Si ni l'un ni l'autre n'apparaît, le r-component se poursuit jusqu'à la fin de l'URN. Notez que les caractères hors de la plage ASCII [RFC20] doivent être encodés en pourcentage à l'aide de la méthode définie à la section 2.1 de la spécification URI générique [RFC3986] (MUST).

Comme décrit à la section 3, le r-component ne doit pas être pris en compte lors de la détermination de l'URN-equivalence (SHALL NOT). Toutefois, le r-component doit être fourni avec l'URN lors de la présentation d'une requête à un service de résolution d'URN (SHALL).

Le présent document ne définit que la syntaxe du r-component et le réserve pour un usage futur. La sémantique exacte du r-component et son utilisation dans les protocoles de résolution d'URN relèvent d'une normalisation potentielle dans des spécifications distinctes, comprenant vraisemblablement des spécifications qui définissent des conventions et un registre pour les identificateurs de services de résolution.

Considérons l'exemple hypothétique de la transmission de paramètres à un service de résolution (disons, un code de pays ISO alpha-2 [ISO.3166-1] afin de sélectionner le pays préféré dans lequel rechercher un exemplaire physique d'un livre). Cela pourrait peut-être s'accomplir en spécifiant le code de pays dans le r-component, ce qui donnerait des URN tels que :

urn:example:foo-bar-baz-qux?+CCResolve:cc=uk

Bien que ce qui précède serve d'explication générale et d'illustration de l'intention des r-component, ceux-ci comportent de nombreuses questions ouvertes, notamment leur relation avec les mécanismes de résolution associés à l'espace de noms URN particulier au moment de l'enregistrement. Ainsi, les r-component ne devraient pas être utilisés pour des URN avant que leur sémantique n'ait été normalisée (SHOULD NOT).

2.3.2. q-component​

Le q-component est destiné à transmettre des paramètres soit à la ressource nommée, soit à un système pouvant fournir le service demandé, en vue de leur interprétation par cette ressource ou ce système. (En revanche, la transmission de paramètres aux services de résolution d'URN est traitée par les r-component comme décrit dans la section précédente.)

Le q-component d'URN a la même syntaxe que le composant de requête d'un URI, mais il est introduit par "?=" et non par "?" seul. Pour un URN susceptible d'être résolu en un URI qui est un localisateur, la sémantique du q-component est identique à celle du composant de requête de cet URI. Ainsi, les résolveurs d'URN qui renvoient un URI qui est un localisateur pour un URN doté d'un q-component le font en copiant le q-component de l'URN vers le composant de requête de l'URI. Un exemple de l'opération de copie figure ci-dessous.

La présente spécification ne spécifie pas de comportement requis dans le cas d'une résolution d'URN vers un URI qui est un localisateur lorsque l'URN d'origine a un q-component et que l'URI a une chaîne de requête. Des circonstances différentes peuvent exiger des approches différentes. Les résolveurs devraient documenter leur stratégie dans de tels cas (SHOULD).

Si l'URN ne se résout pas en un URI qui est un localisateur, l'interprétation du q-component n'est pas définie par la présente spécification. Pour les URN susceptibles d'être résolus en un URI qui est un localisateur, la sémantique du q-component est identique à celle des requêtes adressées à la ressource localisée via cet URI.

Par souci de cohérence avec la RFC 3986, la syntaxe générale et la sémantique des q-component ne sont pas définies par l'espace de noms URN de l'URN, ni dépendantes de celui-ci. Parallèlement à la RFC 3986, les détails de syntaxe et de sémantique, par exemple quels mots clés ou termes sont significatifs, peuvent bien sûr dépendre d'un espace de noms URN particulier ou même d'une ressource particulière.

La séquence "?=" introduit le q-component. Le q-component se termine par un caractère "#" (dièse, qui commence un f-component). Si ce caractère n'apparaît pas, le q-component se poursuit jusqu'à la fin de l'URN. Les caractères barre oblique ("/") et point d'interrogation ("?") peuvent représenter des données à l'intérieur du q-component. Notez que les caractères hors de la plage ASCII [RFC20] doivent être encodés en pourcentage à l'aide de la méthode définie à la section 2.1 de la spécification URI générique [RFC3986] (MUST).

Comme décrit à la section 3, le q-component ne doit pas être pris en compte lors de la détermination de l'URN-equivalence (SHALL NOT).

Les espaces de noms URN et le placement des informations associées dans la syntaxe devraient être conçus de manière à éviter tout besoin pour un service de résolution de tenir compte du q-component (SHOULD). Les systèmes de résolution propres à un espace de noms et les systèmes plus génériques ne doivent pas exiger que les informations du q-component leur soient transmises pour traitement (MUST NOT).

Considérons l'exemple hypothétique de la transmission de paramètres à une application qui renvoie des bulletins météorologiques pour différentes régions ou pour différentes périodes. Cela pourrait peut-être s'accomplir en spécifiant des coordonnées de latitude et de longitude ainsi que des dates et heures dans le q-component de l'URN, ce qui donnerait des URN tels que les suivants.

urn:example:weather?=op=map&lat=39.56
   &lon=-104.85&datetime=1969-07-21T02:56:15Z

Si cet exemple se résolvait en un URI HTTP, le résultat pourrait ressembler à :

https://weatherapp.example?op=map&lat=39.56
   &lon=-104.85&datetime=1969-07-21T02:56:15Z

2.3.3. f-component​

Le f-component est destiné à être interprété par le client comme une spécification d'un emplacement à l'intérieur de la ressource nommée, ou d'une région de celle-ci. Il distingue les parties constitutives d'une ressource nommée par un URN. Pour un URN qui se résout en un ou plusieurs localisateurs pouvant être déréférencés vers une représentation, ou lorsque le résolveur d'URN renvoie directement une représentation de la ressource, la sémantique d'un f-component est définie par le type de média de la représentation.

Le f-component d'URN a la même syntaxe que le composant de fragment d'un URI. Si un URN contenant un f-component se résout en un URI unique qui est un localisateur associé à la ressource nommée, le f-component de l'URN peut être appliqué (généralement par le client) comme le fragment de cet URI. Si l'URN ne se résout pas en un URI qui est un localisateur, l'interprétation du f-component n'est pas définie par la présente spécification. Ainsi, pour les URN susceptibles d'être résolus en un URI qui est un localisateur, la sémantique des f-component est identique à celle des fragments pour cette ressource.

Par souci de cohérence avec la RFC 3986, ni la syntaxe générale ni la sémantique des f-component ne sont définies par l'espace de noms URN de l'URN, ni dépendantes de celui-ci. Parallèlement à la RFC 3986, les détails de syntaxe et de sémantique, par exemple quels mots clés ou termes sont significatifs, peuvent bien sûr dépendre d'un espace de noms URN particulier ou même d'une ressource particulière.

Le f-component est introduit par le caractère dièse ("#") et se termine à la fin de l'URI. Tout caractère hors de la plage ASCII [RFC20] apparaissant dans le f-component doit être encodé en pourcentage à l'aide de la méthode définie à la section 2.1 de la spécification URI générique [RFC3986] (MUST).

Comme décrit à la section 3, le f-component ne doit pas être pris en compte lors de la détermination de l'URN-equivalence (SHALL NOT).

Les clients ne devraient pas transmettre de f-component aux services de résolution, sauf si ces services exécutent aussi des fonctions de récupération et d'interprétation d'objets (SHOULD NOT).

Considérons l'exemple hypothétique de l'obtention de ressources qui font partie d'une entité plus grande (disons, les chapitres d'un livre). Chaque partie pourrait être spécifiée dans le f-component, ce qui donnerait des URN tels que :

urn:example:foo-bar-baz-qux#somepart