6. Definieren und Registrieren eines URN-Namensraums

6.1. Überblick

Weil der Raum der URN-Namensräume selbst verwaltet wird, sollte die Definition eines URN-Namensraums besonderes Augenmerk auf Folgendes legen (SHOULD):

1. Den Zweck des URN-Namensraums.

2. Die Syntax der innerhalb des URN-Namensraums zugewiesenen URNs, einschließlich der internen Syntax und der erwarteten Auswirkungen von r-components oder q-components. (Die Syntax und Interpretation von f-components sind in RFC 3986 definiert.)

3. Das Verfahren zur Zuweisung von URNs innerhalb des URN-Namensraums.

4. Die Sicherheitsimplikationen der Zuweisung von URNs innerhalb des URN-Namensraums und der Verwendung der zugewiesenen URNs.

5. Alle potenziellen Interoperabilitätsprobleme mit innerhalb des URN-Namensraums zugewiesenen URNs.

6. Optional das Verfahren zur Auflösung der innerhalb des URN-Namensraums zugewiesenen URNs.

Der Abschnitt über das Ausfüllen der Vorlage (Abschnitt 6.4) erläutert diese Angelegenheiten ausführlicher. Obwohl die Registrierungsvorlagen in allen Fällen dieselben sind, werden je nach Herkunft der Registrierung leicht unterschiedliche Verfahren verwendet.

6.2. Registrierungsrichtlinie und -verfahren: Gemeinschaftsregistrierungen

Die grundlegende Registrierungsrichtlinie für URN-Namensräume ist Expert Review, wie im IANA-Considerations-Dokument [RFC5226] definiert. Für URN-Namensräume oder deren Definitionen, die zu Standards oder Bestandteilen von Standards werden sollen, ist das Ergebnis des Expert-Review-Verfahrens ein Bericht und nicht eine Anweisung an IANA, tätig zu werden (siehe unten). Die wichtigsten Schritte sind:

1. Die URN-Namensraum-Registrierungsvorlage ausfüllen (siehe Abschnitt 6.4 und Anhang A). Dies kann als Teil eines Internet-Drafts oder einer Spezifikation in einer anderen Reihe geschehen, obwohl das keine Voraussetzung ist.

2. Die ausgefüllte Vorlage zur Prüfung an die Diskussionsliste [email protected] senden.

3. Falls erforderlich, um eingegangene Kommentare zu berücksichtigen, die Schritte 1 und 2 wiederholen.

4. Wenn die Designated Experts dem Antrag zustimmen und keine Standardisierungsmaßnahme damit verbunden ist, wird IANA den beantragten NID registrieren. Wird eine Standardisierung erwartet, werden die Designated Experts einen Bericht erstellen und ihn an die zuständige Standardisierungsgenehmigungsstelle weiterleiten (im Fall der IETF an die IESG); IANA wird den beantragten NID erst registrieren, nachdem sie Anweisungen von jener Stelle und eine Kopie des Expert-Review-Berichts erhalten hat.

Eine URN-Namensraum-Registrierung kann durch Aktualisierung der Registrierungsvorlage überarbeitet werden, wobei dieselben oben für neue Registrierungen dargelegten Schritte befolgt werden. Eine überarbeitete Registrierung muss die Unterschiede zu früheren Versionen beschreiben (MUST) und sollte relevante Änderungen an den zugrunde liegenden Technologien oder den URN-Namensraum-Verwaltungsprozessen besonders vermerken (SHOULD).

Die bisherige Erfahrung mit URN-Namensraum-Registrierungsanträgen hat gezeigt, dass Registranten anfangs manchmal einige der Feinheiten von URN-Namensräumen nicht verstehen und dass die Definition des URN-Namensraums in Form einer Spezifikation es den Registranten ermöglicht, ihren "Vertrag" mit der beabsichtigten Nutzergemeinschaft klar zu formulieren. Obwohl die Registrierungsrichtlinie für formale URN-Namensräume Expert Review ist und eine Spezifikation (im Unterschied zur Registrierungsvorlage) nicht strikt erforderlich ist, sollten Registranten daher eine stabile Spezifikation bereitstellen, die die URN-Namensraum-Definition dokumentiert und die hierin beschriebenen Fragen ausführt (SHOULD).

Da Benennung schwierig und umstritten sein kann, werden URN-Namensraum-Registranten und die Designated Experts nachdrücklich ermutigt, in einem Geist des guten Glaubens und des gegenseitigen Verständnisses zusammenzuarbeiten, um einen groben Konsens (siehe [RFC7282]) über die Behandlung von Registrierungsanträgen zu erzielen. Sie werden auch ermutigt, zusätzliche Fachkenntnis in die Diskussion einzubringen, wenn dies hilfreich wäre, um Perspektive zu bieten oder Fragen anderweitig zu klären.

Insbesondere wenn sich die Iterationen im Registrierungsverfahren in die Länge ziehen, wird von den Designated Experts erwartet, dass sie angemessene Vorkehrungen treffen, um "Race Conditions" bei vorgeschlagenen NIDs zu vermeiden, und dass sie, falls solche Situationen auftreten, Antragsteller dazu ermutigen, etwaige Konflikte untereinander auszuräumen.

6.3. Registrierungsrichtlinie und -verfahren: Schnellverfahren für Normungsorganisationen, wissenschaftliche Gesellschaften und ähnliche Einrichtungen

Die IETF erkennt an, dass Situationen entstehen werden, in denen URN-Namensräume geschaffen werden, um entweder bestehende und etablierte Standards, insbesondere Identifikatorstandards, einzubetten oder Wissen, Terminologie oder Methoden der Informationsorganisation widerzuspiegeln, die weit außerhalb des Zuständigkeitsbereichs der IETF oder der voraussichtlichen Fachkenntnis ihrer Designated Experts liegen. In Situationen, in denen der Registrierungsantrag von einer anerkannten Normungsorganisation, einer wissenschaftlichen Gesellschaft oder deren Beauftragten stammt oder von ihnen autorisiert wurde, steht nach Wahl jener Einrichtung ein etwas anderes Verfahren zur Verfügung:

1. Die URN-Namensraum-Registrierungsvorlage wird wie in den Schritten 1 und 2 von Abschnitt 6.2 ausgefüllt und eingereicht.

2. Eine Spezifikation ist erforderlich, die die benötigten externen Standards oder Spezifikationen widerspiegelt oder auf sie verweist. Eine Veröffentlichung in der RFC-Reihe oder über einen IETF-Prozess (z. B. das Einstellen als Internet-Draft) wird nicht erwartet und wäre nur unter sehr ungewöhnlichen Umständen angemessen.

3. Die Prüfungen auf der Diskussionsliste und durch die Designated Experts sind strikt beratend, wobei die Entscheidungen darüber, welcher Rat angenommen wird, und die für das Verfahren vorgesehene Zeitspanne strikt unter der Kontrolle der externen Einrichtung liegen.

4. Wenn jene Einrichtung zu dem Schluss gelangt, dass der Antrag ausreichend ausgereift ist, werden ihre Vertreter IANA bitten, die Registrierung des NID abzuschließen, und IANA wird dies tun.

Entscheidungen darüber, ob die anfragende Instanz als Normungsorganisation oder wissenschaftliche Gesellschaft anerkannt wird, liegen in der Verantwortung der IESG.

Ein ähnliches Modell wurde bereits für anerkannte Normungsorganisationen definiert, die Medientypen registrieren möchten. Das jenen Mechanismus beschreibende Dokument [RFC6838] bietet etwas mehr Informationen über den allgemeinen Ansatz.

6.4. Ausfüllen der Vorlage

Eine Vorlage zum Definieren und Registrieren eines URN-Namensraums wird in Anhang A bereitgestellt. Dieser Abschnitt beschreibt Überlegungen zum Ausfüllen der Vorlage.

6.4.1. Zweck

Der Abschnitt "Zweck" der Vorlage beschreibt Angelegenheiten wie:

1. Die Arten von Ressourcen, die durch innerhalb des URN-Namensraums zugewiesene URNs identifiziert werden.

2. Den Umfang und die Anwendbarkeit der innerhalb des URN-Namensraums zugewiesenen URNs; dies könnte Informationen über die Nutzergemeinschaft (z. B. eine bestimmte Nation, Branche, Technologie oder Organisation) umfassen, darüber, ob die zugewiesenen URNs in öffentlichen oder privaten Netzen verwendet werden usw.

3. Wie die beabsichtigte Gemeinschaft (und die Internetgemeinschaft insgesamt) davon profitieren wird, die zugewiesenen URNs zu verwenden oder aufzulösen.

4. Wie der URN-Namensraum mit bestehenden URN-Namensräumen, URI-Schemata und Nicht-URN-Identifikatorsystemen zusammenhängt und diese ergänzt.

5. Die Arten von Softwareanwendungen, die die zugewiesenen URNs verwenden oder auflösen können (z. B. indem sie zwischen verschiedenen URN-Namensräumen unterscheiden, Ressourcen auf persistente Weise identifizieren oder Dienste, die dem URN-Namensraum zugeordnet sind, sinnvoll auflösen und darauf zugreifen).

6. Ob Auflösungsdienste verfügbar sind oder sein werden (und, falls ja, die Art oder Identität der Dienste). Beispiele für die Semantik und Syntax von q-components und (sobald sie standardisiert sind) r-components sind hier hilfreich, auch wenn ausführliche Definitionen an anderer Stelle oder später bereitgestellt werden.

7. Ob erwartet wird, dass der URN-Namensraum oder seine Definition Bestandteil eines Standards wird, der in der IETF oder einem anderen anerkannten Normungsgremium entwickelt wird.

6.4.2. Syntax

Der Abschnitt "Syntax" der Vorlage enthält:

1. Eine Beschreibung der Struktur der URNs innerhalb des URN-Namensraums in Übereinstimmung mit der grundlegenden URN-Syntax. Die Struktur könnte anhand einer formalen Definition (z. B. unter Verwendung von ABNF [RFC5234]), eines Algorithmus zur Erzeugung konformer URNs oder eines regulären Ausdrucks zum Parsen des Namens in seine Bestandteile beschrieben werden; alternativ könnte die Struktur undurchsichtig sein.

2. Alle besonderen Zeichenkodierungsregeln für zugewiesene URNs (z. B. welches Zeichen stets für Anführungszeichen verwendet werden sollte).

3. Regeln zur Bestimmung der URN-Equivalence zwischen zwei Namen im URN-Namensraum. Solche Regeln sollten stets die Wirkung haben, falsch-negative Ergebnisse zu beseitigen, die andernfalls aus dem Vergleich resultieren könnten. Wenn es angemessen und hilfreich ist, kann auf bestimmte in der URI-Spezifikation [RFC3986] definierte Äquivalenzregeln oder auf Abschnitt 3 dieses Dokuments verwiesen werden. Beispiele für Regeln zur URN-Equivalence sind die Äquivalenz zwischen Groß- und Kleinbuchstaben in der NSS, zwischen mit Bindestrich versehenen und nicht mit Bindestrich versehenen Gruppierungen im Namen oder zwischen einfachen und doppelten Anführungszeichen. Es kann auch namensraumspezifische besondere Kodierungsüberlegungen geben, insbesondere für URNs, die eingebettete Formen von Namen aus Nicht-URN-Identifikatorsystemen enthalten. (Beachten Sie, dass dies keine normativen Aussagen für irgendeine Art von bewährter Praxis im Umgang mit Beziehungen zwischen Zeichen im Allgemeinen sind; solche Aussagen sind auf einen einzelnen URN-Namensraum beschränkt.)

4. Alle besonderen Überlegungen, die zur Übereinstimmung mit der URN-Syntax erforderlich sind. Dies gilt besonders für bestehende Nicht-URN-Identifikatorsysteme, die im Kontext von URNs verwendet werden. Wenn zum Beispiel ein Nicht-URN-Identifikatorsystem in anderen Kontexten als URNs verwendet wird, könnte es Zeichen nutzen, die in der URN-Syntax reserviert sind. Dieser Abschnitt sollte alle derartigen Zeichen vermerken und die erforderlichen Abbildungen zur Übereinstimmung mit der URN-Syntax umreißen. Normalerweise wird dies durch Prozentkodierung des Zeichens gehandhabt, wie in Abschnitt 2.1 der URI-Spezifikation [RFC3986] spezifiziert und in Abschnitt 1.2.2 dieser Spezifikation erörtert.

5. Alle besonderen Überlegungen zur Bedeutung von q-components (z. B. Schlüsselwörter) oder f-components (z. B. vordefinierte Begriffe) im Kontext dieses URN-Namensraums.

6.4.3. Zuweisung

Der Abschnitt "Zuweisung" der Vorlage beschreibt Angelegenheiten wie:

1. Mechanismen oder zuständige Stellen für die Zuweisung von URNs an Ressourcen. Es sollte klarstellen, ob die Zuweisung vollständig offen (z. B. nach einem bestimmten Verfahren wie first-come, first-served (FCFS)), vollständig geschlossen (z. B. für eine private Organisation) oder in verschiedener Weise eingeschränkt ist (z. B. an von einer bestimmten Organisation anerkannte Stellen delegiert); wenn sie eingeschränkt ist, sollte es erklären, wie man ein Zuweiser von Namen wird oder wie man die Zuweisung von Namen bei bestehenden Zuweisungsstellen beantragt.

2. Methoden zur Sicherstellung, dass URNs innerhalb des URN-Namensraums eindeutig sind. Zum Beispiel könnten Namen von einer einzigen Stelle sequenziell oder nach einem wohldefinierten Prozess zugewiesen werden, die Zuweisung könnte unter delegierten Stellen aufgeteilt werden, die jeweils für die Einhaltung der Eindeutigkeitsregeln verantwortlich sind, oder URNs könnten unabhängig nach einem Algorithmus erzeugt werden, der selbst die Eindeutigkeit garantiert.

6.4.4. Sicherheit und Datenschutz

Der Abschnitt "Sicherheit und Datenschutz" der Vorlage beschreibt alle potenziellen Probleme im Zusammenhang mit Sicherheit und Datenschutz hinsichtlich der Zuweisung, Verwendung und Auflösung von Namen innerhalb des URN-Namensraums. Beispiele für solche Probleme sind:

• Die Folgen der Erzeugung falsch-negativer und falsch-positiver Ergebnisse beim Vergleich auf URN-Equivalence (siehe Abschnitt 3.1 dieser Spezifikation und "Issues in Identifier Comparison for Security Purposes" [RFC6943]).

• Das Durchsickern privater Informationen, wenn Namen im öffentlichen Internet übermittelt werden.

• Das Potenzial für Directory Harvesting.

• Verschiedene Probleme, die in den Richtlinien für Sicherheitsüberlegungen in RFCs [RFC3552] und den Datenschutzüberlegungen für Internetprotokolle [RFC6973] erörtert werden. Beachten Sie insbesondere den Datenschutzüberlegungstext für den Namensraum der Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) [RFC7254], der ein nützliches Modell für solche Fälle bieten könnte.

6.4.5. Interoperabilität

Der Abschnitt "Interoperabilität" muss alle bekannten potenziellen Probleme im Zusammenhang mit der Interoperabilität spezifizieren (MUST). Beispiele sind mögliche Verwechslungen mit anderen URN-Namensräumen, Nicht-URN-Identifikatorsystemen oder URI-Schemata aufgrund der Syntax (z. B. Prozentkodierung bestimmter Zeichen) oder des Umfangs (z. B. überlappende Interessenbereiche). Wenn irgend möglich, sollten Bedenken, die während der Registrierung eines URN-Namensraums auftreten (z. B. aufgrund der Syntax oder des Umfangs eines Nicht-URN-Identifikatorsystems), als Teil des Registrierungsverfahrens oder parallel dazu ausgeräumt werden.

6.4.6. Auflösung

Der Abschnitt "Auflösung" muss spezifizieren, ob Auflösungsmechanismen für innerhalb des URN-Namensraums zugewiesene URNs beabsichtigt oder zu erwarten sind (MUST).

Wenn eine Auflösung beabsichtigt ist, sollte dieser Abschnitt spezifizieren, ob die Organisation, die URNs innerhalb des URN-Namensraums zuweist, beabsichtigt, Auflösungsdienste für URNs innerhalb jenes URN-Namensraums zu betreiben oder zu empfehlen (SHOULD). Wenn die zuweisende Organisation außerdem eine Registrierung für öffentlich bekannt gemachte Auflösungsdienste implementieren will (zum Beispiel unter Verwendung eines Systems, das im Geiste der ursprünglichen Architekturprinzipien und Dienstbeschreibungen für die URN-Auflösung [RFC2276] [RFC2483] entwickelt wurde), dann sollte dieser Abschnitt die Anforderungen für die öffentliche Bekanntmachung durch die zuweisende Organisation auflisten oder referenzieren (SHOULD). Darüber hinaus sollte dieser Abschnitt alle besonderen Überlegungen für die Handhabung von r-components im Kontext dieses URN-Namensraums beschreiben (SHOULD).

6.4.7. Zusätzliche Informationen

Der Abschnitt "Zusätzliche Informationen" enthält Informationen, die für diejenigen nützlich wären, die diese Registrierung oder ihre Beziehung zu anderen Registrierungen verstehen wollen, wie etwa Vergleiche mit bestehenden URN-Namensräumen, die sich möglicherweise zu überlappen scheinen.

Dieser Abschnitt der Vorlage ist optional.