Zusammenfassung

  • RFC8141 lässt die optionalen Komponenten r, q und f bei der Prüfung der URN-Namensgleichheit außer Betracht. Daraus folgt keine allgemeine Erlaubnis, sie aus Dienstanfragen zu entfernen.
  • q richtet sich an die benannte Ressource oder ein System, das einen Dienst bereitstellt. Ein Resolver darf diese Informationen nicht für seine eigene Verarbeitung voraussetzen. Beim beschriebenen Rückgabefall einer Locator-URI wird q in deren Query übernommen; für eine bereits vorhandene Query ist kein verbindliches Kombinationsverhalten festgelegt.
  • r erhält in RFC8141 einen syntaktischen Platz, während seine Semantik künftiger Standardisierung vorbehalten bleibt. Namensvergleich, Gültigkeit, Repräsentationsauswahl und Zugriffsentscheidung benötigen jeweils eigene Grundlagen. Eine gemeinsame Identität macht den Resolver nicht zur zentralen Genehmigungsstelle für jede Nutzung.

Ein Vergleichsergebnis mit zu vielen Aufgaben

Ein Team könnte einen URN-Vergleicher einführen, um doppelte Indexeinträge zu vermeiden. Die anschließende Versuchung ist naheliegend: Warum nicht dieselbe bereinigte Form auch zur Erzeugung von Anfragen und zur Auswahl gespeicherter Antworten verwenden? Eine Funktion weniger, eine Schnittstelle weniger, ein einheitlicher Schlüssel. Die Einsparung ist plausibel. Doch der Schlüssel beantwortet zunächst nur eine Frage über Namen, nicht alle späteren Fragen über die Verwendung der benannten Ressource.

Dieses Szenario ist hypothetisch. Der Artikel berichtet keinen solchen Fehler eines überprüften Produkts. Es zeigt vielmehr, wo eine Architekturregel durch eine scheinbar praktische Verallgemeinerung ihren Gegenstand wechseln kann. RFC8141, veröffentlicht im April 2017, beschreibt Syntax und Gleichheit von Uniform Resource Names innerhalb des URI-Systems. Optionale Komponenten erlauben es, zusätzliche Informationen mitzuführen. Nicht jede davon gehört zum Namen, der verglichen wird; daraus folgt nicht, dass sie für jeden Empfänger bedeutungslos wäre.

Die grundlegende Gleichheitsprüfung ist enger als eine beliebige Zeichenkettennormalisierung. urn und der Namespace Identifier NID werden hinsichtlich der Groß- und Kleinschreibung vereinheitlicht. Die hexadezimalen Buchstaben A bis F in den Prozentkodierungen des Namespace Specific String NSS werden großgeschrieben. Der NSS wird nicht insgesamt kleingeschrieben. Prozentkodierungen werden für diese Prüfung auch nicht nach Belieben dekodiert. Ein allgemeines Textwerkzeug kann zusätzliche Änderungen vornehmen, die diese Regel nicht rechtfertigt.

r, q und f gehen nicht in den Namensvergleich ein. Ein Index muss deshalb nicht für jede Nutzungsoption oder jede Position innerhalb einer Repräsentation einen anderen Namen anlegen. Ein Vergleichsschlüssel kann diesen Zweck erfüllen, während die ursprüngliche Anfrage getrennt erhalten bleibt. Wer stattdessen schon am Eingang die optionalen Bestandteile endgültig entfernt, trifft eine andere Entscheidung: Welche Informationen können nachfolgende Akteure überhaupt noch sehen?

Ein Namensraum kann weitere Gleichheitsregeln vorgeben und dadurch falsch negative Ergebnisse vermindern. Er darf damit keine Gleichheit aufheben, die nach dem grundlegenden Verfahren bereits feststeht. Diese Grenze schützt eine gemeinsame Mindestbeziehung, ohne dem allgemeinen Vergleicher die vollständige Kenntnis aller Namensraumregeln aufzubürden. Lokale Spezialisierung und eine feste gemeinsame Basis schließen einander nicht aus.

Der Unterschied hat organisatorische Folgen. Der Index ordnet Namen. Der Resolver arbeitet innerhalb seines Auflösungsauftrags. Ein Ressourcendienst interpretiert Informationen, die an ihn gerichtet sind. Ein Client behandelt gegebenenfalls eine Position in einer erhaltenen Repräsentation. Würde die Indexfunktion die Eingabe aller anderen Rollen vorab beschneiden, wäre das nicht bloß eine interne Speicheroptimierung. Es würde Entscheidungsmaterial verschieben oder vernichten.

q ist nicht der Geschäftsauftrag des Resolvers

Die q-Komponente beginnt mit ?=. Ihre Informationen sind für die benannte Ressource oder das System bestimmt, das einen Dienst anbietet. Ob unterschiedliche Werte tatsächlich unterschiedliche Repräsentationen ergeben, hängt vom jeweiligen Kontext ab. Der Artikel behauptet weder eine universelle Ergebnisdifferenz noch universelle Ergebnisgleichheit. Entscheidend ist die begrenzte Aussage: Namensgleichheit allein beweist nicht, dass diese Informationen aus sämtlichen Anfragen entfernt werden können.

RFC8141 verbietet dem Resolver, q-Informationen für seine eigene Verarbeitung vorauszusetzen. Dieses MUST NOT begrenzt seine funktionale Abhängigkeit. Er muss nicht sämtliche ressourcenspezifischen Nutzungsbedingungen verstehen, um einen Namen aufzulösen. Es verbietet aber nicht die Existenz eines anderen Empfängers für diese Informationen. Ein Vermittler kann etwas weiterreichen, ohne dessen vollständige Semantik selbst zu kontrollieren.

Für den beschriebenen Fall, in dem die Auflösung eine Locator-URI liefert, wird q in den Query-Teil dieser URI kopiert. Die bei der Gleichheitsprüfung ignorierte Komponente bekommt damit eine Aufgabe in einem anderen Schritt. Man muss diesen Fall benennen, statt die Regel ungeprüft auf jede Art von Auflösungsergebnis auszudehnen. Der Anwendungsbereich gehört zur Aussage; ohne ihn wird aus einer nachvollziehbaren Vorgabe eine unbelegte Universalbehauptung.

Wenn die gefundene Adresse schon eine Query hat

Die Kopie in eine bisher leere Stelle ist nicht der schwierige Fall. Schwieriger wird es, wenn die gefundene Locator-URI bereits eine Query enthält. Dann treffen Informationen aus der eingehenden URN auf Informationen der Zieladresse. Denkbar sind verschiedene Kombinationen und Prioritäten. RFC8141 schreibt dafür kein verbindliches Verhalten vor. Stattdessen sollte der Resolver seine Strategie dokumentieren.

Diese Empfehlung erklärt weder alle Strategien für wirkungsgleich, noch ermächtigt sie einen Prüfer, eine bevorzugte Kombination zum allgemeinen Standard zu erklären. Sie macht eine örtlich getroffene Verarbeitungsentscheidung zum Gegenstand einer nachvollziehbaren Dienstzusage. Die gemeinsame Namensregel bleibt bestehen, während der Nutzer die konkrete Konstruktion seiner Anfrage anhand der Erklärung des Anbieters beurteilen kann.

In einer kontrollierten Prüfung ließe sich ein Name mit q auf eine Adresse mit vorhandener Query auflösen. Man würde zuerst das Vergleichsergebnis, dann die konstruierte URI und anschließend, soweit der Versuch es vorsieht, die erhaltene Repräsentation erfassen. Diese Prüfungen wurden hier nicht durchgeführt. Sie sind ein Vorschlag, wie sich verschiedene Behauptungen getrennt testen lassen, ohne jeden textlichen Unterschied als zwingende Inhaltsdifferenz zu behandeln.

Gerade beim Anbieterwechsel ist die Trennung wertvoll. Ein Team kann sich an die Strategie seines ersten Resolvers gewöhnen und sie für eine Eigenschaft des gesamten URN-Systems halten. Ein anderer Resolver sieht dann wie ein Standardbruch aus, obwohl er in einem nicht verbindlich festgelegten Bereich anders entscheidet. Eine veröffentlichte Strategie beseitigt nicht jede Abhängigkeit. Sie zeigt jedoch, welche Abhängigkeit aus einer lokalen Zusage stammt und nicht aus der grundlegenden Namensgleichheit.

Beschaffung kann hier mehr Erklärung verlangen, als ein knappes Kompatibilitätsversprechen liefert. Sie sollte das Verlangen aber richtig begründen. RFC8141 empfiehlt die Dokumentation; eine bestimmte universelle Überschreibungsreihenfolge steht dort nicht. Wer eine solche Reihenfolge als zusätzliches Vertragsmerkmal benötigt, muss sie als zusätzliche Zusage vereinbaren. Eine Lücke in der Beschreibung ist kein Beleg dafür, dass die gemeinsame Norm heimlich die bevorzugte Produktentscheidung anordnet.

Ein syntaktischer Platz bleibt zunächst ein Platz

r beginnt mit ?+ und ist für Informationen an den Auflösungsdienst vorgesehen. RFC8141 legt die Syntax fest, reserviert die Semantik aber für spätere Standardisierung. Die Komponente sollte vor einer Standardisierung ihrer Semantik nicht verwendet werden. Ein Parser, der die Zeichenfolge annimmt, weist deshalb noch keinen interoperablen Dienstbefehl nach. Formale Erkennbarkeit und betriebliche Verfügbarkeit sind unterschiedliche Belege.

Die Aussage ist auf diese Spezifikation beschränkt. Die Recherche weist nicht nach, dass weltweit keine spätere Norm r definiert hätte. Sie hat auch keine aktuelle Implementierung auf Unterstützung geprüft. Man darf aus der reservierten Syntax des RFC8141 lediglich nicht ohne weitere Evidenz ein bereits vollständig beschriebenes Auflösungsprotokoll machen. Eine tatsächlich relevante spätere Spezifikation müsste gesondert betrachtet werden.

f, nach #, richtet sich dagegen auf eine Position oder Region, die der Client behandelt. Im beschriebenen Fall des Repräsentationsabrufs folgt die Bedeutung der Fragmentangabe dem Medientyp der Repräsentation. Diese begrenzte Zuordnung ist keine einheitliche Semantik für sämtliche möglichen Auflösungsergebnisse. Ebenso wenig muss der Resolver deshalb alle Medientypen verstehen. Die Angabe vom Namensvergleich auszunehmen und für ihren richtigen Empfänger zu erhalten, ist kein Widerspruch.

Die drei Komponenten als beliebige optionale Anhänge zusammenzufassen, würde gerade diese Unterschiede verschleiern. Syntax, Empfänger und Stand der semantischen Festlegung sind nicht identisch. Keiner der Anhänge erzeugt allein eine Zugriffsberechtigung. Keiner wird allein durch seine Nichtberücksichtigung im Vergleich für jede spätere Verarbeitung entbehrlich. Eine Rollenverteilung ist genauer als eine allgemeine Regel, alles zu entfernen oder alles zentral zu interpretieren.

Was das ISSN-Beispiel tatsächlich belegt

Das IANA-Register und die erhaltenen Registrierungsdokumente für ISBN und ISSN zeigen auch eine weitere Grenze. Die Gültigkeit eines Namens hängt von einem registrierten Namensraum und dessen Vergaberegeln ab. Eine syntaktisch plausible Zeichenfolge beweist keine gültige Zuteilung. Namensgleichheit beweist wiederum keine Erlaubnis für eine bestimmte Operation an der Ressource. Diese Fragen dürfen nicht durch dasselbe Ja des Vergleichers ersetzt werden.

Im erhaltenen ISSN-Dokument kann der mittlere Bindestrich bei der Gleichheitsprüfung entfallen; Q und R werden dabei nicht berücksichtigt. Bei der Auflösung sind dagegen Prüfziffer und mittlerer Bindestrich relevant, einschließlich einer beschriebenen lokalen Wiedereinfügung des fehlenden Bindestrichs. Das illustriert getrennte Regeln für getrennte Schritte. Der Artikel berichtet keinen Versuch mit einer realen ISSN oder ISBN und keine Prüfung eines heutigen Resolverdienstes.

RFC8254 hat 2017 die ISBN- und ISSN-Registrierungen überführt und RFC3044 sowie RFC3187 abgelöst. Die Praxis der ISO-Identifikatoren kann sich entwickeln, ohne für jede Anpassung wieder dasselbe formelle Genehmigungsverfahren des Registrierungstextes durchlaufen zu müssen. Das erhaltene Dokument ist darum nicht als vollständiger Bericht über die jüngste ISO-Praxis zu lesen. Historische Registrierungsevidenz und heutiges Betriebsverhalten bleiben verschiedene Quellenarten.

Der Antwortcache hat einen anderen Gegenstand

Folgt auf die Auflösung ein Abruf über HTTP, gelten in diesem späteren Schritt die entsprechenden Cache-Regeln. Nach RFC9111 besteht der Cacheschlüssel mindestens aus der Anfragemethode und der Ziel-URI. Vary wirkt bei der Auswahl gespeicherter Antworten anhand relevanter Anfragefelder. Die grundlegende URN-Namensgleichheit ersetzt diese Kriterien nicht.

Das ist eine Aussage über die HTTP-Stufe, nicht über jeden URN-Resolver oder jede denkbare Speicherung. Unterschiedliche URIs bedeuten auch nicht zwingend unterschiedliche Inhalte. Entscheidend ist, dass ein Namensindex und ein Antwortcache verschiedene Gegenstände ordnen. Ein gemeinsames technisches Format für Schlüssel reicht nicht aus, um ihre Wiederverwendungsbedingungen gleichzusetzen. Die gemeinsame Identität der Ressource beantwortet noch nicht die Frage nach der passenden Antwort auf einen konkreten Abruf.

RFC3401 bietet mit DDDS historischen Auflösungskontext, schreibt aber nicht für jeden URN-Dienst dieselbe Verfahrenskette vor. Der in RFC6963 beschriebene Namensraum example dient der Illustration. Er belegt nicht, dass ein konkreter Name von einer produktiven Infrastruktur aufgelöst wird. Architekturbeispiele und Betriebsevidenz erfüllen unterschiedliche Aufgaben; aus einem anschaulichen Beispiel entsteht kein nachgewiesenes Produktmerkmal.

RFC8820 beschäftigt sich mit dem angemessenen Kontrollumfang von Spezifikationen für URI-Strukturen. Die Webarchitektur des W3C unterscheidet Identifikation, Interaktion und Repräsentation und beschreibt eine technische Beziehung der Kontrolle über URIs. Diese Grundlagen helfen, Verantwortlichkeiten zu sortieren. Sie liefern keine rechtliche Nutzungslizenz und keine Zugriffsberechtigung allein aufgrund eines Namens.

Lu Heng beschreibt eine minimale Anfangsspezifikation, lokalisierte künftige Entscheidungen und freiwillige Übernahme. Als redaktioneller Bezug verdeutlicht das, was eine gemeinsame Schicht hier leisten kann: Namen erkennbar machen und die Grenzen der Komponenten festlegen. Sie muss nicht jedes ressourcenspezifische Verfahren im Voraus entscheiden oder jede spätere Anfrage erneut genehmigen. Der Resolver erklärt seine Strategie; Ressourcendienst und Client behandeln die ihnen zugeordneten Informationen.

Eine solche Verteilung braucht dennoch überprüfbare Zusagen. Wo die Spezifikation keine verbindliche Kombination festlegt, wird die Erklärung des Dienstanbieters wichtiger, nicht unwichtiger. Ein Versprechen von Beständigkeit oder allgemeiner Normtreue beantwortet die vorhandene Query nicht. Gute Grenzen lassen erkennen, welcher Teil gemeinsam feststeht und welcher Teil von einem lokalen Anbieter verantwortet wird.

Die Gleichheit eines Namens ist damit ein Ausgangspunkt für Koordination. Sie ist kein Befehl zur Austauschbarkeit sämtlicher Dienstanfragen. Wer den Vergleich auf seinen Gegenstand begrenzt und Informationen für die folgenden Schritte erhalten kann, schafft einen klareren Vertrag, ohne eine neue zentrale Genehmigungsinstanz einzuführen.

Quellen