2. URN-Syntax
Wie oben erörtert, erlaubt die Syntax für URNs in dieser Spezifikation deutlich mehr Funktionalität als in den früheren Spezifikationen, zuletzt [RFC2141]. Sie ist zudem mit der allgemeinen URI-Syntax [RFC3986] harmonisiert (die, wie angemerkt werden muss, nach den früheren URN-Spezifikationen fertiggestellt wurde).
Diese Spezifikation erweitert die URN-Syntax jedoch nicht, um die direkte Verwendung von Zeichen außerhalb des ASCII-Bereichs [RFC20] zu erlauben. Diese Einschränkung bedeutet, dass solche Zeichen prozentkodiert werden müssen, wie in Abschnitt 2.1 der URI-Spezifikation [RFC3986] beschrieben.
Die grundlegende Syntax für einen URN wird unter Verwendung der Augmented Backus-Naur Form (ABNF) definiert, wie in [RFC5234] spezifiziert. Regeln, die hier nicht definiert sind (insbesondere alphanum, fragment und pchar), sind als Teil der URI-Syntax [RFC3986] definiert und werden hier verwendet, um die syntaktische Beziehung zu den dort verwendeten Begriffen aufzuzeigen. Die Definitionen einiger der unten verwendeten Begriffe sind nicht umfassend; zusätzliche Einschränkungen ergeben sich aus dem Fließtext in Abschnitten dieses Dokuments, die für jene Begriffe spezifisch sind (insbesondere r-component in Abschnitt 2.3.1 und q-component in Abschnitt 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
Das Fragezeichen "?" kann innerhalb von r-components, q-components und f-components ohne Prozentkodierung verwendet werden. Außerhalb dieser Komponenten ist ein "?", auf das nicht unmittelbar "=" oder "+" folgt, für URNs nicht definiert und sollte von URN-spezifischen Parsern und anderen Verarbeitern als Syntaxfehler behandelt werden (SHOULD).
Die folgenden Abschnitte bieten zusätzliche Informationen über die syntaktischen Elemente von URNs.
2.1. Namensraumidentifikator (NID)
NIDs unterscheiden nicht zwischen Groß- und Kleinschreibung (z. B. sind "ISBN" und "isbn" äquivalent).
Zeichen außerhalb des ASCII-Bereichs [RFC20] sind in NIDs nicht zulässig, und es wird kein Kodierungsmechanismus für solche Zeichen unterstützt.
Die Abschnitte 5.1 und 5.2 erlegen den Zeichenketten, die als NIDs verwendet werden können, zusätzliche Beschränkungen auf, d. h. die oben gezeigte Syntax ist nicht umfassend.
2.2. Namensraumspezifische Zeichenkette (NSS)
Die NSS ist eine Zeichenkette, 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 dem NID (eindeutig im gesamten "urn"-Schema) und der NSS (eindeutig innerhalb des URN-Namensraums) stellt sicher, dass der resultierende URN global eindeutig ist.
Die in diesem Dokument spezifizierte NSS erlaubt mehrere Zeichen, die von früheren Spezifikationen nicht zugelassen wurden (siehe Anhang B). Insbesondere das Zeichen "/", das nun erlaubt ist, ermöglicht es faktisch, hierarchische Namen aus Nicht-URN-Identifikatorsystemen zu kapseln. Man betrachte etwa das hypothetische Beispiel eines hierarchischen Identifikatorsystems, in dem die Namen die Form einer Folge von durch das Zeichen "/" getrennten Zahlen haben, wie "1/406/47452/2". Würde die zuständige Stelle für solche Namen URNs verwenden, so wäre es natürlich, den vorhandenen Namen in die NSS zu setzen, was URNs wie "urn:example:1/406/47452/2" ergäbe.
Diese Änderungen an der Syntax für die NSS ändern nicht die Kodierungsregeln für URN-Namensräume, die in Übereinstimmung mit [RFC2141] definiert wurden. Wenn ein solcher URN-Namensraum, dessen Namen außerhalb des URN-Kontexts (d. h. in einem Nicht-URN-Identifikatorsystem) verwendet werden, auch die Verwendung von "/", "~" oder "&" in der nativen Form innerhalb jenes Identifikatorsystems erlaubt, dann werden die Kodierungsregeln für jenen URN-Namensraum durch diese Spezifikation nicht geändert.
Je nach den Regeln, die ein Nicht-URN-Identifikatorsystem und den zugehörigen URN-Namensraum bestimmen, können Namen, die in jenem Identifikatorsystem gültig sind, Zeichen enthalten, die von der oben referenzierten "pchar"-Produktion nicht zugelassen werden (z. B. Zeichen außerhalb des ASCII-Bereichs oder, in Übereinstimmung mit den Beschränkungen in RFC 3986, die Zeichen "/", "?", "#", "[" und "]"). Während ein solcher Name innerhalb des Nicht-URN-Identifikatorsystems gültig sein mag, ist er kein gültiger URN, bis er in eine NSS übersetzt wurde, die den Regeln jenes bestimmten URN-Namensraums entspricht. Bei URNs, die aus Namen gebildet werden, die in einem Nicht-URN-Identifikatorsystem separat existieren, erfolgt die Übersetzung eines Namens von seinem "nativen" Format in ein URN-Format unter Verwendung der für URNs im Allgemeinen definierten Kanonisierungs- und Kodierungsmethoden oder spezifischer Regeln für jenen URN-Namensraum. Software, die die namensraumspezifischen Kanonisierungs- und Kodierungsregeln nicht kennt, darf keine URNs aus dem Namen im Nicht-URN-Identifikatorsystem konstruieren (MUST NOT).
Insbesondere im Hinblick auf Zeichen außerhalb des ASCII-Bereichs müssen URNs, die in Protokollen erscheinen oder zwischen Systemen übergeben werden, ausschließlich Unicode-Zeichen verwenden, die in UTF-8 kodiert und gemäß den Anforderungen von RFC 3986 weiter kodiert sind (MUST). Soweit machbar und mit den Anforderungen von anderweitig definierten und standardisierten Namen sowie mit den in Abschnitt 1.2 erörterten Prinzipien vereinbar, sollten die zur Darstellung von Namen verwendeten Zeichen entweder auf ASCII-Buchstaben und -Ziffern beschränkt werden oder auf die Zeichen und die Syntax einiger weit verbreiteter Modelle wie derjenigen von Internationalizing Domain Names in Applications (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) [RFC7613] oder der Unicode Identifier and Pattern Syntax specification [UAX31] (SHOULD).
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] zulassen, es sei denn, die Natur des jeweiligen URN-Namensraums macht solche Zeichen erforderlich (SHOULD NOT).
2.3. Optionale Komponenten
Diese Spezifikation enthält drei optionale Komponenten in der URN-Syntax. Sie werden als r-component, q-component und f-component bezeichnet und weiter unten ausführlicher beschrieben. Da sich diese Spezifikation fast ausschließlich auf die URN-Syntax konzentriert, definiert sie keine detaillierte Semantik dieser Komponenten für URNs im Allgemeinen. Jede dieser Komponenten hat jedoch eine eigene Rolle, die von einem gegebenen URN und seinem URN-Namensraum unabhängig ist. Es ist beabsichtigt, dass Clients diese Komponenten für alle URNs einheitlich handhaben können. Diese Komponenten können mit URNs aus bestehenden URN-Namensräumen verwendet werden, unabhängig davon, ob ein URN-Namensraum sie ausdrücklich unterstützt (MAY). In Übereinstimmung mit dem in RFC 3986 gewählten Ansatz ist jedoch das Verhalten eines URN, der Komponenten enthält, die für einen bestimmten URN-Namensraum oder eine Ressource undefiniert oder bedeutungslos sind, nicht definiert. Die folgenden Abschnitte beschreiben diese optionalen Komponenten und ihre Interpretation ausführlicher.
2.3.1. r-component
Die r-component ist dafür gedacht, Parameter an URN-Auflösungsdienste zu übergeben (im weiten Sinne, siehe Abschnitt 1.2) und von diesen Diensten interpretiert zu werden. (Im Gegensatz dazu wird das Übergeben von Parametern an die durch einen URN identifizierten Ressourcen oder an Anwendungen, die solche Ressourcen verwalten, durch q-components gehandhabt, wie im nächsten Abschnitt beschrieben.)
Die URN-r-component hat kein syntaktisches Gegenstück in irgendeinem anderen bekannten URI-Schema.
Die Sequenz "?+" leitet die r-component ein. Die r-component endet mit einer Sequenz "?=" (die eine q-component beginnt) oder mit einem Zeichen "#" (Nummernzeichen, das eine f-component beginnt). Wenn keines von beiden auftritt, setzt sich die r-component bis zum Ende des URN fort. Beachten Sie, dass Zeichen außerhalb des ASCII-Bereichs [RFC20] unter Verwendung der in Abschnitt 2.1 der generischen URI-Spezifikation [RFC3986] definierten Methode prozentkodiert werden müssen (MUST).
Wie in Abschnitt 3 beschrieben, darf die r-component bei der Bestimmung der URN-Equivalence nicht berücksichtigt werden (SHALL NOT). Beim Vorlegen einer Anfrage an einen URN-Auflösungsdienst muss die r-component jedoch zusammen mit dem URN mitgeliefert werden (SHALL).
Dieses Dokument definiert nur die Syntax der r-component und reserviert sie für künftige Verwendung. Die genaue Semantik der r-component und ihre Verwendung in URN-Auflösungsprotokollen sind Gegenstand einer möglichen Standardisierung in separaten Spezifikationen, vermutlich einschließlich Spezifikationen, die Konventionen und eine Registry für Auflösungsdienst-Identifikatoren definieren.
Man betrachte das hypothetische Beispiel, Parameter an einen Auflösungsdienst zu übergeben (etwa einen ISO-Alpha-2-Ländercode [ISO.3166-1], um das bevorzugte Land auszuwählen, in dem nach einem physischen Exemplar eines Buches gesucht werden soll). Dies könnte vielleicht dadurch erreicht werden, dass der Ländercode in der r-component angegeben wird, was URNs wie die folgenden ergäbe:
urn:example:foo-bar-baz-qux?+CCResolve:cc=uk
Während das Obige als allgemeine Erläuterung und Veranschaulichung der Absicht hinter r-components dienen sollte, gibt es damit viele offene Fragen, einschließlich ihrer Beziehung zu Auflösungsmechanismen, die zum Zeitpunkt der Registrierung mit dem jeweiligen URN-Namensraum verbunden sind. Daher sollten r-components nicht für URNs verwendet werden, bevor ihre Semantik standardisiert wurde (SHOULD NOT).
2.3.2. q-component
Die q-component ist dafür gedacht, Parameter entweder an die benannte Ressource oder an ein System zu übergeben, das den angeforderten Dienst bereitstellen kann, zur Interpretation durch jene Ressource oder jenes System. (Im Gegensatz dazu wird das Übergeben von Parametern an URN-Auflösungsdienste durch r-components gehandhabt, wie im vorherigen Abschnitt beschrieben.)
Die URN-q-component hat dieselbe Syntax wie die URI-Query-Komponente, wird aber durch "?=" eingeleitet und nicht durch "?" allein. Für einen URN, der zu einem URI aufgelöst werden kann, der ein Locator ist, ist die Semantik der q-component identisch mit der für die Query-Komponente jenes URI. Daher tun URN-Resolver, die einen URI zurückgeben, der ein Locator für einen URN mit einer q-component ist, dies, indem sie die q-component vom URN in die Query-Komponente des URI kopieren. Ein Beispiel für den Kopiervorgang erscheint unten.
Diese Spezifikation legt kein erforderliches Verhalten für den Fall der URN-Auflösung zu einem URI fest, der ein Locator ist, wenn der ursprüngliche URN eine q-component hat und der URI eine Query-Zeichenkette hat. Unterschiedliche Umstände können unterschiedliche Vorgehensweisen erfordern. Resolver sollten ihre Strategie in solchen Fällen dokumentieren (SHOULD).
Wenn der URN nicht zu einem URI auflöst, der ein Locator ist, ist die Interpretation der q-component durch diese Spezifikation nicht definiert. Für URNs, die zu einem URI aufgelöst werden können, der ein Locator ist, ist die Semantik der q-component identisch mit der für Abfragen an die über jenen URI lokalisierte Ressource.
Um der Konsistenz mit RFC 3986 willen werden die allgemeine Syntax und die Semantik von q-components nicht durch den URN-Namensraum des URN definiert und sind nicht von ihm abhängig. Parallel zu RFC 3986 können Einzelheiten der Syntax und Semantik, z. B. welche Schlüsselwörter oder Begriffe bedeutungstragend sind, natürlich von einem bestimmten URN-Namensraum oder sogar von einer bestimmten Ressource abhängen.
Die Sequenz "?=" leitet die q-component ein. Die q-component endet mit einem Zeichen "#" (Nummernzeichen, das eine f-component beginnt). Wenn dieses Zeichen nicht auftritt, setzt sich die q-component bis zum Ende des URN fort. Die Zeichen Schrägstrich ("/") und Fragezeichen ("?") können Daten innerhalb der q-component darstellen. Beachten Sie, dass Zeichen außerhalb des ASCII-Bereichs [RFC20] unter Verwendung der in Abschnitt 2.1 der generischen URI-Spezifikation [RFC3986] definierten Methode prozentkodiert werden müssen (MUST).
Wie in Abschnitt 3 beschrieben, darf die q-component bei der Bestimmung der URN-Equivalence nicht berücksichtigt werden (SHALL NOT).
URN-Namensräume und die zugehörige Platzierung von Informationen in der Syntax sollten so gestaltet werden, dass kein Auflösungsdienst die q-component berücksichtigen muss (SHOULD). Namensraumspezifische und allgemeinere Auflösungssysteme dürfen nicht verlangen, dass ihnen q-component-Informationen zur Verarbeitung übergeben werden (MUST NOT).
Man betrachte das hypothetische Beispiel, Parameter an eine Anwendung zu übergeben, die Wetterberichte aus verschiedenen Regionen oder für verschiedene Zeiträume zurückgibt. Dies könnte vielleicht dadurch erreicht werden, dass Breiten- und Längengradkoordinaten sowie Datums-/Zeitangaben in der q-component des URN angegeben werden, was URNs wie die folgenden ergäbe.
urn:example:weather?=op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z
Wenn dieses Beispiel zu einem HTTP-URI aufgelöst würde, könnte das Ergebnis so aussehen:
https://weatherapp.example?op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z
2.3.3. f-component
Die f-component ist dafür gedacht, vom Client als Spezifikation für einen Ort innerhalb der benannten Ressource oder eine Region davon interpretiert zu werden. Sie unterscheidet die Bestandteile einer durch einen URN benannten Ressource. Für einen URN, der zu einem oder mehreren Locators auflöst, die zu einer Repräsentation dereferenziert werden können, oder bei dem der URN-Resolver direkt eine Repräsentation der Ressource zurückgibt, wird die Semantik einer f-component durch den Medientyp der Repräsentation definiert.
Die URN-f-component hat dieselbe Syntax wie die URI-Fragment-Komponente. Wenn ein URN, der eine f-component enthält, zu einem einzelnen URI auflöst, der ein der benannten Ressource zugeordneter Locator ist, kann die f-component aus dem URN (üblicherweise vom Client) als das Fragment jenes URI angewendet werden. Wenn der URN nicht zu einem URI auflöst, der ein Locator ist, ist die Interpretation der f-component durch diese Spezifikation nicht definiert. Somit ist für URNs, die zu einem URI aufgelöst werden können, der ein Locator ist, die Semantik von f-components identisch mit der von Fragmenten für jene Ressource.
Um der Konsistenz mit RFC 3986 willen werden weder die allgemeine Syntax noch die Semantik von f-components durch den URN-Namensraum des URN definiert oder sind von ihm abhängig. Parallel zu RFC 3986 können Einzelheiten der Syntax und Semantik, z. B. welche Schlüsselwörter oder Begriffe bedeutungstragend sind, natürlich von einem bestimmten URN-Namensraum oder sogar von einer bestimmten Ressource abhängen.
Die f-component wird durch das Nummernzeichen ("#") eingeleitet und durch das Ende des URI beendet. Alle Zeichen außerhalb des ASCII-Bereichs [RFC20], die in der f-component auftreten, müssen unter Verwendung der in Abschnitt 2.1 der generischen URI-Spezifikation [RFC3986] definierten Methode prozentkodiert werden (MUST).
Wie in Abschnitt 3 beschrieben, darf die f-component bei der Bestimmung der URN-Equivalence nicht berücksichtigt werden (SHALL NOT).
Clients sollten f-components nicht an Auflösungsdienste übergeben, es sei denn, jene Dienste führen auch Funktionen zum Abrufen und Interpretieren von Objekten aus (SHOULD NOT).
Man betrachte das hypothetische Beispiel, Ressourcen zu erhalten, die Teil einer größeren Einheit sind (etwa die Kapitel eines Buches). Jeder Teil könnte in der f-component angegeben werden, was URNs wie die folgenden ergäbe:
urn:example:foo-bar-baz-qux#somepart