Zum Hauptinhalt springen

4. URI-Konformität

4.1. Verwendung in URI-Protokoll-Slots​

Weil ein URN syntaktisch ein URI unter dem "urn"-Schema ist, kann ein URN theoretisch in jeden Protokoll-Slot gesetzt werden, der einen URI zulässt (um nur einige zu nennen: die Attribute "href" und "src" in HTML, das base-Element in HTML, das Attribut "xml:base" in XML [XML-BASE] und das Attribut "xmlns" in XML für XML-Namensraum-Namen [XML-NAMES]).

Dies impliziert jedoch nicht, dass es semantisch in der Praxis immer sinnvoll ist, einen URN in einen gegebenen URI-Protokoll-Slot zu setzen; insbesondere, weil ein URN möglicherweise nicht den Ort einer Ressource angibt oder sogar nur indirekt auf eine verweist, könnte es unangemessen sein, einen URN in einen URI-Protokoll-Slot zu setzen, der auf eine Ressource verweist (z. B. die zuvor genannten Attribute "href" und "src").

Letztlich liegt die Verantwortung für Richtlinien dazu, wann die Verwendung von URIs unter dem "urn"-Schema (oder einem anderen Schema) angemessen ist, bei den Spezifikationen für die einzelnen URI-Protokoll-Slots (z. B. könnte die Spezifikation für das Attribut "xml:base" in XML empfehlen, dass die Verwendung von URNs in jenem Protokoll-Slot unangemessen ist). Diese Spezifikation kann unmöglich alle relevanten Fälle vorhersehen, und es ist nicht ihre Aufgabe, die Verwendung für einzelne Protokoll-Slots vorzuschreiben oder einzuschränken.

4.2. Parsen​

Teils wegen der Trennung der URN-Semantik von der allgemeineren URI-Syntax müssen generische URI-Prozessoren den Parsing- und Analyseregeln von RFC 3986 besondere Aufmerksamkeit widmen und insbesondere den URI als undurchsichtig behandeln, sofern das Schema und seine Anforderungen nicht erkannt werden. Im letzteren Fall können solche Prozessoren in der Lage sein, eine schemaangemessene Verarbeitung anzustoßen, z. B. durch einen URN-Resolver. Ein URN-Resolver kann entweder ein externer Resolver sein, den der URI-Resolver kennt, oder eine in den URI-Resolver eingebaute Funktionalität sein. Beachten Sie, dass diese Anforderung Beschränkungen für die Kontexte auferlegen könnte, in denen URNs angemessen verwendet werden; siehe Abschnitt 4.1.

4.3. URNs und relative Referenzen​

Abschnitt 5.2 von [RFC3986] beschreibt einen Algorithmus zum Umwandeln einer URI-Referenz, die relativ zu einer gegebenen Basis-URI sein kann, in "parsed components" des Ziels jener Referenz, die dann gemäß RFC 3986, Abschnitt 5.3, zu einer Ziel-URI wieder zusammengesetzt werden können. Dieser Algorithmus ist für URNs problematisch, weil ihre Syntax die erforderlichen Pfadkomponenten nicht unterstützt. Wird der Algorithmus jedoch unabhängig von einem bestimmten Schema angewendet, sollte er auch für URNs vorhersehbar funktionieren, mit den folgenden Maßgaben (Terminologie der Syntaxproduktionen aus RFC 3986):

  1. Ein System, das auf eine <URI-reference> stößt, die der Syntax für <relative-ref> folgt, gleichgültig ob sie ausdrücklich das Schema "urn" hat oder nicht, wird sie in eine Ziel-URI umwandeln, wie in RFC 3986 spezifiziert.

  2. Aufgrund der Erwartungen an Persistenz und Stabilität von URNs sollten Verfasser von Dokumenten usw., die URNs nutzen, im Allgemeinen die Verwendung des "urn"-Schemas in jeder <URI-reference> vermeiden, die nicht strikt eine <URI> gemäß RFC 3986 ist, insbesondere einschließlich solcher, die eine Verarbeitung von <relative-ref> erfordern würden.

4.4. Transport und Darstellung​

Wenn URNs transportiert und ausgetauscht werden, müssen sie in dem hierin definierten Format dargestellt werden (MUST). Darüber hinaus werden URN-fähige Anwendungen nachdrücklich ermutigt, die Option anzubieten, URNs in dieser kanonischen Form anzuzeigen, um eine direkte Übernahme (zum Beispiel durch Kopieren-und-Einfügen) zu ermöglichen. Solche Anwendungen könnten die Anzeige von URNs in einer menschenfreundlicheren Form unterstützen und einen Zeichensatz verwenden, der Zeichen enthält, die in der in dieser Spezifikation definierten URN-Syntax nicht zulässig sind (z. B. könnten solche Anwendungen beim Anzeigen von URNs für Menschen prozentkodierte Zeichenketten durch Zeichen aus einem erweiterten Zeichenrepertoire wie Unicode [UNICODE] ersetzen).

Um Verwirrung bei Benutzern zu minimieren, sollte jede Anwendung, die URIs anzeigt, den vollständigen URI anzeigen (bei URNs einschließlich des "urn"-Schemas und aller Komponenten), um sicherzustellen, dass keine Verwechslung zwischen URN-NIDs und URI-Schema-Identifikatoren entsteht (SHOULD). Zum Beispiel unterscheidet sich ein URI, der mit "urn:xmpp:" [RFC4854] beginnt, sehr von einem URI, der mit "xmpp:" [RFC5122] beginnt. In ähnlicher Weise unterscheidet sich ein potenzielles URI-Schema für Digital Object Identifier (DOI) [DOI-URI] von einem möglichen DOI-URN-Namensraum und ist möglicherweise völlig unabhängig von diesem.

4.5. URI-Design und -Eigentümerschaft​

Wie erwähnt, ist die Zuweisung von URNs innerhalb eines URN-Namensraums ein verwalteter Prozess, ebenso wie die Zuweisung der URN-Namensräume selbst. Obwohl das Design der innerhalb eines gegebenen URN-Namensraums zuzuweisenden URNs durch diese Spezifikation an den URN-Namensraum-Manager abgetreten wird, vermeidet ein verwaltetes Vorgehen dabei die Probleme, die der unverwalteten Erzeugung von URIs innewohnen, wie sie in den Empfehlungen zu URI-Design und -Eigentümerschaft [RFC7320] beschrieben sind.