1. Einleitung

Ein Uniform Resource Name (URN) ist ein Uniform Resource Identifier (URI) [RFC3986], der unter dem "urn"-URI-Schema und einem bestimmten URN-Namensraum zugewiesen wird, mit der Absicht, dass der URN ein persistenter, ortsunabhängiger Ressourcenidentifikator sein wird. Ein URN-Namensraum ist eine Sammlung solcher URNs, von denen jeder (1) eindeutig ist, (2) auf konsistente und verwaltete Weise zugewiesen wird und (3) nach einer gemeinsamen Definition zugewiesen wird. (Einige URN-Namensräume erzeugen Namen, die nur als URNs existieren, während andere URNs auf der Grundlage von Namen zuweisen, die bereits in Nicht-URN-Identifikatorsystemen erstellt wurden, wie ISBNs [RFC3187], ISSNs [RFC3044] oder RFCs [RFC2648].)

Die Zuweisung von URNs erfolgt durch eine Organisation (oder in manchen Fällen nach einem Algorithmus oder einem anderen automatisierten Verfahren), der formell ein URN-Namensraum innerhalb des "urn"-Schemas delegiert wurde (z. B. könnte ein URN im URN-Namensraum "example" [RFC6963] die Form "urn:example:foo" haben).

Dieses Dokument beruht auf zwei zentralen Annahmen:

1. Die Zuweisung eines URN ist ein verwalteter Prozess.

2. Der Raum der URN-Namensräume ist selbst verwaltet.

Während andere URI-Schemata zulassen mögen, dass Ressourcenidentifikatoren frei gewählt und zugewiesen werden, ist dies bei URNs nicht der Fall. Die syntaktische Korrektheit eines Namens, der mit "urn:" beginnt, reicht nicht aus, um ihn zu einem URN zu machen. Damit der Name ein gültiger URN ist, muss der Namensraumidentifikator (NID) gemäß den hier definierten Regeln registriert werden, und die übrigen Teile des assigned-name-Anteils des URN müssen gemäß den Regeln für den registrierten URN-Namensraum erzeugt werden.

Damit Informationen sowohl über die URN-Syntax als auch über URN-Namensräume an einer Stelle verfügbar sind, tut dieses Dokument Folgendes:

1. Es definiert die kanonische Syntax für URNs im Allgemeinen (auf eine Weise, die mit der URI-Syntax konsistent ist), spezifiziert Methoden zur Bestimmung der URN-Equivalence und erörtert die URI-Konformität.

2. Es spezifiziert eine Methode zum Definieren eines URN-Namensraums und zu dessen Verknüpfung mit einem bestimmten NID und beschreibt Verfahren zur Registrierung von URN-NIDs bei der Internet Assigned Numbers Authority (IANA).

In Bezug auf die URN-Syntax und URN-Namensräume modernisiert und ersetzt dieses Dokument die ursprünglichen Spezifikationen für die URN-Syntax [RFC2141] sowie für die Definition und Registrierung von URN-Namensräumen [RFC3406]. Diese Änderungen bauen auf den zentralen Anforderungen auf, die in der ursprünglichen Funktionsbeschreibung für URNs [RFC1737] dargelegt wurden, sowie auf den Lehren aus vielen Jahren Erfahrung. In jenen ursprünglichen Dokumenten und im vorliegenden ist die Absicht, URNs auf konsistente Weise zu definieren, sodass – wo immer praktikabel – das Parsen, die Handhabung und die Auflösung von URNs unabhängig von dem URN-Namensraum sein können, innerhalb dessen ein gegebener URN zugewiesen ist.

Zusammen mit Beiträgen mehrerer wichtiger Nutzergemeinschaften erzwangen die Geschichte und die Erfahrungen mit URNs eine Erweiterung der URN-Definition, um neue Funktionalität zu unterstützen, einschließlich der Verwendung von Syntax, die in RFC 2141 ausdrücklich für die künftige Standardisierung reserviert war. Alle URN-Namensräume und URNs, die unter den früheren Spezifikationen gültig waren, bleiben gültig, auch wenn es nützlich sein mag, die Definitionen einiger URN-Namensräume zu aktualisieren, um neue Merkmale zu nutzen.

Die vorstehenden Überlegungen können zusammen mit verschiedenen Unterschieden zwischen URNs und URIs, die Locators sind (insbesondere URLs), sowie der stärkeren Ausrichtung auf URLs in RFC 3986 als dem endgültigen Nachfolger von [RFC1738] und [RFC1808] zu manchen Interpretationen von RFC 3986 und dieser Spezifikation führen, die nicht vollständig konsistent erscheinen (oder es vielleicht tatsächlich nicht sind), insbesondere im Hinblick auf Handlungen oder Semantiken jenseits der grundlegenden Syntax selbst. Treten solche Situationen auf, sollten Erörterungen von URNs und URN-Namensräumen gemäß diesem Dokument interpretiert werden und nicht durch Extrapolation aus RFC 3986.

Zusammenfassungen der Änderungen gegenüber den RFCs 2141 und 3406 finden sich in Anhang B bzw. C. Dieses Dokument macht sowohl [RFC2141] als auch [RFC3406] obsolet. Obwohl es [RFC1737] oder [RFC2276] nicht ausdrücklich aktualisiert oder ersetzt, sollte sich der Leser, der jene Dokumente heranzieht, darüber im Klaren sein, dass das konzeptionelle Modell von URNs in diesem Dokument sich geringfügig von jenen älteren Spezifikationen unterscheidet.

1.1. Terminologie

Die folgenden Begriffe werden wie unten beschrieben voneinander unterschieden:

URN: Ein URI (wie in RFC 3986 definiert), der das "urn"-Schema verwendet und sowohl die Eigenschaften eines "name" gemäß der Beschreibung in jenem Dokument als auch die in diesem Dokument beschriebenen Eigenschaften aufweist. Der Begriff bezieht sich auf den gesamten URI einschließlich seiner optionalen Komponenten. Hinweis für den Leser: Der Begriff "URN" wurde in anderen Kontexten verwendet, um einen URN-Namensraum, den Namensraumidentifikator, den assigned-name und URIs zu bezeichnen, die nicht das "urn"-Schema verwenden. Alle diese außer dem letzten werden an anderer Stelle in diesem Dokument mit spezifischerem Vokabular beschrieben; aufgrund jener anderen Verwendungen sollte der Begriff jedoch mit Sorgfalt verwendet und interpretiert werden.

Locator: Ein Identifikator, der ein Mittel zum Zugriff auf eine Ressource bereitstellt.

Identifikatorsystem: Eine verwaltete Sammlung von Namen. Dieses Dokument bezeichnet Identifikatorsysteme außerhalb des Kontexts von URNs als "Nicht-URN-Identifikatorsysteme".

URN-Namensraum: Ein Identifikatorsystem, das einem URN-NID zugeordnet ist.

NID: Der einem URN-Namensraum zugeordnete Identifikator.

NSS: Der für den URN-Namensraum spezifische Teil eines URN.

assigned-name: Die Kombination aus dem "urn:"-Schema, dem NID und der namensraumspezifischen Zeichenkette (NSS). Ein "assigned-name" ist folglich eine Teilzeichenkette eines URN (wie oben definiert), wenn dieser URN zusätzliche Komponenten enthält (siehe Abschnitt 2).

Der Begriff "name" wird hier bewusst nicht definiert und sollte (und wird in der Praxis) nur sehr informell verwendet werden. RFC 3986 verwendet den Begriff als eine von "locator" unterschiedene Kategorie von URI (Abschnitt 1.1.3), gebraucht ihn aber auch in anderen Kontexten. Würden diese Verwendungen als definitionisch behandelt, so stünden sie im Widerspruch etwa zur Vorstellung von URN-Namensraum-Namen (d. h. NIDs) und zu Begriffen, die mit Nicht-URN-Identifikatorsystemen verbunden sind.

Dieses Dokument verwendet die Begriffe "resource", "identifier", "identify", "dereference", "representation" und "metadata" ungefähr so, wie sie in der URI-Spezifikation [RFC3986] definiert sind.

Dieses Dokument verwendet die Begriffe "resolution" und "resolver" ungefähr in dem Sinne, in dem sie in der ursprünglichen Erörterung der Architekturprinzipien für URNs [RFC2276] verwendet wurden, d. h. "resolution" ist die Handlung, Dienste im Zusammenhang mit der identifizierten Ressource bereitzustellen, etwa den persistenten URN in einen oder mehrere aktuelle Locators für die Ressource zu übersetzen, Metadaten über die Ressource in einem geeigneten Format zu liefern oder sogar eine Repräsentation der Ressource (z. B. ein Dokument) zu liefern, ohne weitere Vermittler zu benötigen. Zum Zeitpunkt dieses Schreibens werden Auflösungsdienste in [RFC2483] beschrieben.

Zur Unterscheidung zwischen Repräsentationen und Metadaten siehe Abschnitt 1.2.2 von [RFC3986].

Mehrere weitere Begriffe im Zusammenhang mit "normalization"-Operationen, die nicht Teil des Unicode-Standards [UNICODE] sind, werden hier ebenfalls so verwendet wie in RFC 3986.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in [RFC2119] beschrieben.

1.2. Entwurfsabwägungen

In einem viel größeren Maße als zu der Zeit, als URNs erstmals erwogen und ihre Verwendungen umrissen wurden (siehe [RFC1737]), bringen Fragen persistenter Identifikatoren im Internet grundlegende Entwurfsabwägungen mit sich, die viel weiter reichen als URNs oder der URN-Ansatz und sogar offene Forschungsfragen innerhalb der Informationswissenschaft berühren. Ideale und umfassende Spezifikationen darüber, was im gesamten Universum der URNs getan oder verlangt werden sollte, würden eine allgemeine Übereinstimmung über eine Vielzahl solcher Fragen und Lösungen dafür erfordern. Während einige dieser Fragen durch die Ansätze des Internet- oder Computerzeitalters zu Zeichenkodierungen und Datenabstraktion aufgeworfen wurden, sind andere Jahrhunderte älter als das Internet und Computersysteme; eine Übereinstimmung über umfassende Lösungen ist in naher Zukunft unwahrscheinlich.

Obwohl diese Spezifikation folglich einige Anforderungen und Flexibilität enthält, die es in einer vollkommeneren Welt nicht gäbe, war dies notwendig, um eine Konsensspezifikation zu erzeugen, die eine modernisierte Definition von URNs bereitstellt (die unattraktive Alternative wäre gewesen, die Definition trotz weit verbreiteter Nutzung nicht zu modernisieren).

Die folgenden Unterabschnitte beschreiben zwei der relevanten Fragen ausführlicher.

1.2.1. Auflösung

Eine Frage, die für URNs spezifisch ist (im Gegensatz zu Namenssystemen im Allgemeinen), ist das recht schwierige Thema der "resolution", das in den Abschnitten 1.1, 2.3.1, 6.4.6 und an weiteren Stellen unten erörtert wird.

Bei traditionellen Uniform Resource Locators (URLs), d. h. bei den meisten URIs, die Locators sind, ist die Auflösung relativ unkompliziert, weil sie dazu dient, einen Zugriffsmechanismus zu bestimmen, der wiederum dazu verwendet wird, den Locator zu dereferenzieren, indem (typischerweise) eine Repräsentation der zugehörigen Ressource wie etwa ein Dokument abgerufen wird (siehe Abschnitt 1.2.2 von [RFC3986]).

Im Gegensatz dazu ist die Auflösung für URNs flexibler und vielfältiger.

Ein wichtiger Fall betrifft die Abbildung eines URN auf einen oder mehrere Locators. In diesem Fall ist das Endergebnis immer noch eine Frage des Dereferenzierens des bzw. der abgebildeten Locators zu einer oder mehreren Repräsentationen. Der wesentliche Unterschied ist hier die Persistenz: Selbst wenn sich ein abgebildeter Locator geändert hat (z. B. hat ein DNS-Domänenname den Besitzer gewechselt und eine URL wurde nicht geändert, um auf einen neuen Ort zu verweisen, oder – in einem extremeren und hypothetischen Fall – wird das DNS vollständig ersetzt), wird ein URN-Nutzer die korrekte Repräsentation (z. B. ein Dokument) erhalten können, solange der Resolver seine URN-zu-Locator-Abbildungen aktuell gehalten hat. Folglich können die relevanten Beziehungen für URNs, die zu Locators auflösen, die wiederum zu einer Repräsentation dereferenziert werden, recht präzise definiert werden.

Diese Spezifikation erlaubt jedoch mehrere andere Fälle der URN-Auflösung sowie URNs für Ressourcen, die keine Informationsabrufsysteme einbeziehen. Dies gilt entweder individuell für bestimmte URNs oder (wie unten definiert) kollektiv für ganze URN-Namensräume.

Man betrachte einen Namensraum von URNs, die zu Locators auflösen, die wiederum nur zu Metadaten über Ressourcen dereferenziert werden, weil die zugrunde liegenden Systeme keine Repräsentationen dieser Ressourcen enthalten; ein Beispiel könnte ein URN-Namensraum für International Standard Name Identifiers (ISNIs) sein, wie dieses Identifikatorsystem im relevanten Standard [ISO.27729.2012] definiert ist, wobei standardmäßig ein URN nur zu einem Metadatensatz aufgelöst würde, der die durch die ISNI identifizierte öffentliche Identität beschreibt.

Man betrachte ferner URNs, die nur dann zu Repräsentationen auflösen, wenn die anfragende Instanz berechtigt ist, die Repräsentation zu erhalten, während andere Instanzen nur Metadaten über die Ressource erhalten können; ein Beispiel könnten Dokumente sein, die in der gesetzlichen Pflichtexemplarsammlung einer Nationalbibliothek aufbewahrt werden.

Schließlich sind manche URNs möglicherweise überhaupt nicht dafür gedacht, zu Locators aufzulösen; Beispiele könnten URNs sein, die XML-Namensraum-Namen identifizieren (z. B. der durch [RFC6288] spezifizierte URN-Namensraum "dgiwg"), URNs, die Anwendungsmerkmale identifizieren, die innerhalb eines Kommunikationsprotokolls unterstützt werden können (z. B. der durch [RFC7462] spezifizierte URN-Namensraum "alert"), und URNs, die Aufzählungstypen wie Werte in einer Registry identifizieren (z. B. könnte ein URN-Namensraum verwendet werden, um die Werte in allen IANA-Registries einzeln zu identifizieren, wie in [IANA-URN] vorläufig vorgeschlagen).

Verschiedene Arten von URNs und mehrere Auflösungsdienste, die für sie verfügbar sein mögen, machen das Konzept der "resolution" für URNs komplizierter, aber auch viel reichhaltiger als den geradlinigen Fall der Auflösung zu einem Locator, der zu einer Repräsentation dereferenziert wird.

1.2.2. Zeichensätze und Kodierungen

Eine ähnliche Reihe von Überlegungen gilt für Zeichensätze und Kodierungen. URNs, insbesondere URNs, die als benutzerorientierte Identifikatoren verwendet werden, sollten in lokalen Sprachen und Schriftsystemen bequem zu verwenden, mit einer breiten Palette von Tastaturen und lokalen Konventionen leicht einzugeben und eindeutig sein. Zwischen diesen Zielen bestehen Abwägungen, und derzeit ist nicht absehbar, wie ein einfacher und leicht verständlicher Regelsatz entwickelt werden könnte, der für alle URNs optimal oder auch nur vernünftig wäre. Die Erörterung in Abschnitt 2.2 definiert einen übergreifenden Rahmen, der generalisiertes Parsen und Verarbeiten ermöglichen sollte, gibt aber auch Empfehlungen zu Regeln für einzelne URN-Namensräume.