2.2. Namensraumspezifischer String (Namespace Specific String - NSS)

Die NSS ist eine Zeichenfolge, die innerhalb eines URN-Namensraums eindeutig ist, auf konsistente Weise zugewiesen und verwaltet wird und der Definition des relevanten URN-Namensraums entspricht. Die Kombination aus NID (eindeutig im gesamten "urn"-Schema) und NSS (eindeutig innerhalb des URN-Namensraums) stellt sicher, dass der resultierende URN global eindeutig ist.

Die NSS, wie in diesem Dokument spezifiziert, erlaubt mehrere Zeichen, die von früheren Spezifikationen nicht zugelassen waren (siehe Anhang B). Insbesondere das Zeichen "/", das jetzt erlaubt ist, macht es effektiv möglich, hierarchische Namen aus Nicht-URN-Bezeichnersystemen zu kapseln. Betrachten Sie beispielsweise das hypothetische Beispiel eines hierarchischen Bezeichnersystems, in dem die Namen die Form einer Sequenz von Zahlen annehmen, die durch das Zeichen "/" getrennt sind, wie "1/406/47452/2". Wenn die Autorität für solche Namen URNs verwenden würde, wäre es natürlich, den vorhandenen Namen in der NSS zu platzieren, was zu URNs wie "urn:example:1/406/47452/2" führt.

Diese Änderungen an der Syntax für die NSS ändern nicht die Kodierungsregeln für URN-Namensräume, die gemäß [RFC2141] definiert wurden. Wenn ein solcher URN-Namensraum, dessen Namen außerhalb des URN-Kontexts (d. h. in einem Nicht-URN-Bezeichnersystem) verwendet werden, auch die Verwendung von "/", "~" oder "&" in der nativen Form innerhalb dieses Bezeichnersystems erlaubt, dann werden die Kodierungsregeln für diesen URN-Namensraum durch diese Spezifikation nicht geändert.

Abhängig von den Regeln, die ein Nicht-URN-Bezeichnersystem und seinen zugehörigen URN-Namensraum regeln, können Namen, die in diesem Bezeichnersystem gültig sind, Zeichen enthalten, die von der oben referenzierten "pchar"-Produktion nicht erlaubt sind (z. B. Zeichen außerhalb des ASCII-Bereichs oder, konsistent mit den Einschränkungen in RFC 3986, die Zeichen "/", "?", "#", "[" und "]"). Während ein solcher Name innerhalb des Nicht-URN-Bezeichnersystems gültig sein kann, ist er kein gültiger URN, bis er in eine NSS übersetzt wurde, die den Regeln dieses bestimmten URN-Namensraums entspricht. Im Fall von URNs, die aus Namen gebildet werden, die separat in einem Nicht-URN-Bezeichnersystem existieren, wird die Übersetzung eines Namens von seinem "nativen" Format in ein URN-Format durch die Verwendung der für URNs im Allgemeinen definierten Kanonisierungs- und Kodierungsmethoden oder spezifischer Regeln für diesen URN-Namensraum erreicht. Software, die sich der namensraumspezifischen Kanonisierungs- und Kodierungsregeln nicht bewusst ist, DARF KEINE URNs aus dem Namen im Nicht-URN-Bezeichnersystem konstruieren.

Insbesondere in Bezug auf Zeichen außerhalb des ASCII-Bereichs MÜSSEN URNs, die in Protokollen erscheinen oder zwischen Systemen übergeben werden, nur Unicode-Zeichen verwenden, die in UTF-8 kodiert und gemäß RFC 3986 weiter kodiert sind. Soweit machbar und konsistent mit den Anforderungen an anderswo definierte und standardisierte Namen sowie den in Abschnitt 1.2 diskutierten Prinzipien SOLLTEN die zur Darstellung von Namen verwendeten Zeichen entweder auf ASCII-Buchstaben und -Ziffern oder auf die Zeichen und Syntax einiger weit verbreiteter Modelle wie die der Internationalisierung von Domänennamen in Anwendungen (IDNA) [RFC5890], Vorbereitung, Durchsetzung und Vergleich internationalisierter Zeichenfolgen (PRECIS) [RFC7613] oder der Unicode-Bezeichner- und Mustersyntaxspezifikation [UAX31] beschränkt werden.

Um URNs so stabil und persistent wie möglich zu machen, wenn sich Protokolle weiterentwickeln und sich die Umgebung um sie herum ändert, SOLLTEN URN-Namensräume KEINE Zeichen außerhalb des ASCII-Bereichs [RFC20] erlauben, es sei denn, die Natur des bestimmten URN-Namensraums macht solche Zeichen erforderlich.