2.2. Chaîne spécifique à l'espace de noms (Namespace Specific String - NSS)
La 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 pertinent. La combinaison du NID (unique dans l'ensemble du schéma "urn") et de la NSS (unique dans l'espace de noms URN) garantit que l'URN résultant est globalement unique.
La NSS telle que spécifiée dans ce document permet plusieurs caractères non autorisés par les spécifications antérieures (voir Annexe B). En particulier, le caractère "/", qui est maintenant autorisé, permet effectivement d'encapsuler des noms hiérarchiques de systèmes d'identifiants non-URN. Par exemple, considérez l'exemple hypothétique d'un système d'identifiants hiérarchiques dans lequel les noms prennent la forme d'une séquence de nombres séparés par le caractère "/", tels que "1/406/47452/2". Si l'autorité pour de tels noms devait utiliser des URN, il serait naturel de placer le nom existant dans la NSS, résultant en des URN tels que "urn:example:1/406/47452/2".
Ces modifications de la syntaxe de la NSS ne modifient pas les règles d'encodage pour les 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'identifiants non-URN) autorise également l'utilisation de "/", "~" ou "&" dans la forme native au sein de ce système d'identifiants, alors les règles d'encodage pour cet espace de noms URN ne sont pas modifiées par cette spécification.
Selon les règles régissant un système d'identifiants non-URN et son espace de noms URN associé, les noms qui sont valides dans ce système d'identifiants peuvent contenir des caractères qui ne sont pas autorisés par la production "pchar" référencée ci-dessus (par exemple, des caractères en dehors de la plage ASCII ou, conformément aux restrictions dans RFC 3986, les caractères "/", "?", "#", "[" et "]"). Bien qu'un tel nom puisse être valide dans le système d'identifiants non-URN, ce n'est pas un URN valide tant qu'il n'a pas été traduit en une 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'identifiants non-URN, la traduction d'un nom de son format "natif" vers un format URN est accomplie en utilisant les méthodes de canonicalisation et d'encodage définies pour les URN en général ou des règles spécifiques pour cet espace de noms URN. Les logiciels qui ne connaissent pas les règles de canonicalisation et d'encodage spécifiques à l'espace de noms NE DOIVENT PAS construire d'URN à partir du nom dans le système d'identifiants non-URN.
En particulier, en ce qui concerne les caractères en dehors de la plage ASCII, les URN qui apparaissent dans les protocoles ou qui sont transmis entre les systèmes DOIVENT utiliser uniquement des caractères Unicode encodés en UTF-8 et encodés davantage comme requis par RFC 3986. Dans la mesure du possible et conformément aux exigences des noms définis et standardisés ailleurs, ainsi qu'aux principes discutés dans la Section 1.2, les caractères utilisés pour représenter les noms DEVRAIENT être limités soit aux 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], Préparation, Application et Comparaison des Chaînes Internationalisées (PRECIS) [RFC7613], ou la spécification de Syntaxe des Identificateurs et Motifs Unicode [UAX31].
Afin de rendre les URN aussi stables et persistants que possible lorsque les protocoles évoluent et que l'environnement autour d'eux change, les espaces de noms URN NE DEVRAIENT PAS autoriser les caractères en dehors de la plage ASCII [RFC20] à moins que la nature de l'espace de noms URN particulier ne rende ces caractères nécessaires.