Zusammenfassung

  • RFC 3404 definierte Auflösung als typisierte Anfrage: I2L, I2R, I2C und I2N verlangten Fundorte, Ressourceninstanzen, Beschreibungen und dauerhafte Namen; Singular und Plural bewahrten zusätzlich die Kardinalität.
  • S, A und U bezeichneten die Darstellung für den nächsten Schritt. P verließ DDDS zugunsten anwendungsspezifischer Verarbeitung. Die Entdeckung eines Resolvers authentisierte weder ihn noch das gelieferte Objekt.

Ein System kann erfolgreich die falsche Frage beantworten. Wer eine Beschreibung verlangt und nur eine Download-Adresse erhält, bekommt etwas Verwandtes, aber nicht Gleichwertiges. Wer die Ressource verlangt und Metadaten erhält, erlebt möglicherweise eine technisch saubere Übertragung mit falscher Bedeutung.

RFC 3404 erschien im Oktober 2002 auf dem Standards Track und definierte DDDS-Anwendungen für URI- und URN-Auflösung. Die Architektur verteilte sich auf fünf Texte: RFC 3401 führte DDDS ein, RFC 3402 beschrieb den Algorithmus, RFC 3403 legte NAPTR-Regeln in DNS ab, RFC 3404 bestimmte die Anwendungen und RFC 3405 verwaltete uri.arpa. und urn.arpa..

Die Verarbeitung begann mit einer anwendungseigenen Zeichenkette. Bei allgemeiner URI-Auflösung wurde die absolute URI kanonisiert und kodiert; ihr Schema lieferte den First Well Known Key, der unter uri.arpa. abgefragt wurde. Für eine URN führte der Namespace Identifier zu urn.arpa.. NAPTR-Regeln schrieben um oder delegierten, bis ein terminales Ergebnis oder ein anderes System erreicht war.

URI- und URN-Anwendung waren technisch gleich, operativ jedoch absichtlich getrennt. URN-Auflösung besaß bereits einen verkürzten Weg und sollte nicht von der Einführung eines universellen URI-Resolvers abhängen. Ein Namensraum konnte damit nützliche Auflösung anbieten, ohne auf die Zustimmung aller URI-Schemata zu warten.

Das Feld Services trug den Ergebnistyp. I2L lieferte eine Orts-URI, I2Ls eine oder mehrere. I2R und I2Rs lieferten Instanzen der Ressource. I2C erzeugte eine Beschreibung, I2N eine URN. Für Letztere warnte der RFC, dass die Gleichheit zweier URNs von Regeln des Namensraums abhängen und mehr als Zeichenvergleich verlangen konnte.

Diese Ergebnisse waren nicht austauschbar. Ein Ort sagt, wo ein Bezug versucht werden kann. Eine Ressourceninstanz ist der tatsächlich gelieferte Inhalt. Eine Beschreibung macht Aussagen darüber. Ein dauerhafter Name soll Identität trotz wechselnder Orte bewahren. Dieselbe Kennung konnte alle Operationen unterstützen, doch der Beleg für eine davon erfüllte keine andere.

Auch Kardinalität gehörte zum Vertrag. Das kleine s in I2Ls und I2Rs erlaubte eine Menge. Bewahrte der Verbraucher nur das erste Element auf, fügte er eine eigene Auswahlpolitik hinzu. Ein Beleg muss angefragten Dienst, Singular oder Plural, vollständige Ergebnismenge und tatsächliche Wahl festhalten.

Vor den Diensten durfte ein optionaler Protokollname stehen. Allein genügte er nicht. RFC 3404 verlangte eine gesonderte Definition der Anfragekodierung und Antwortsemantik. „HTTP“ erklärte weder die Unterscheidung zwischen Orts- und Ressourcenanfrage noch Medientypen für Beschreibungen oder die Darstellung mehrerer Werte.

Diensterkennung erzeugt also keinen Anwendungsvertrag. Beworbene Fähigkeit, beobachtbare Anfrage und typisierte Antwort müssen dieselbe Bedeutung tragen. Sonst erkennen zwei Programme dieselbe Bezeichnung und sprechen weiterhin über verschiedene Dinge.

Flags beschrieb eine zweite Dimension. S, A und U waren DDDS-Terminalflags. S übergab einen Domänennamen an eine SRV-Abfrage, A an eine Adressabfrage und U erzeugte eine URI. Terminal bedeutete das Ende der DDDS-Schleife, nicht das Ende aller Netzarbeit, Authentisierung oder Inhaltsprüfung.

P war grundlegend anders. Es erklärte den Rest zur anwendungsspezifischen Verarbeitung außerhalb der DDDS-Begriffe. Es war kein viertes Terminalformat, sondern eine Kontrollgrenze. Wer es als internes Ende verbuchte, verlor den Nachweis, dass ein anderes Regelsystem die Autorität übernommen hatte.

Die vier Flags waren 2002 gegenseitig ausschließend. Implementierungen durften dennoch nicht annehmen, das Feld werde immer null oder ein Zeichen lang sein; spätere Anwendungen konnten Kombinationen definieren. Bei unbekanntem Flag war der Datensatz zu ignorieren und fortzufahren. Diese Prüfung hatte Vorrang, weil ein neues Flag die Interpretation der restlichen Felder verändern konnte.

Services durfte früh in einer Delegation leer sein. Der Herausgeber kannte Protokoll und Dienst des endgültigen Resolvers womöglich noch nicht. Leer bedeutete weder fehlerhaft noch universell, sondern vertagte die Auswahl.

RFC 3404 erlaubte eine eng begrenzte Optimierung innerhalb derselben ORDER-Gruppe. Ein Client konnte einen besser nutzbaren Dienst suchen, musste aber Ein- und Ausgabe des Grundalgorithmus bewahren. Er durfte keinen anderen Delegationspfad betreten und nach einer Übereinstimmung keinen höheren ORDER prüfen.

Diese Schranke trennte lokale Fähigkeit von veröffentlichter Autorität. Der Client darf unter gleichwertigen Angeboten das beherrschte Protokoll wählen. Er darf keinen bequemen Endpunkt aus einer anderen Autoritätsschicht hochstufen. Sonst würde Optimierung zur stillen Umschreibung der Delegation.

SRV- oder Adressdaten im Additional-Abschnitt konnten Abfragen sparen, waren aber nur Optimierung. Die Anwendung musste ohne sie funktionieren. Nächsten Namen entdecken, Hilfsdaten erhalten und Verbindung vollenden waren drei getrennte Belege.

Sicherheit folgte denselben Grenzen. Einen Resolver zu finden definierte keine sichere Kommunikation; das musste jedes Auflösungsprotokoll leisten. uri.arpa. und urn.arpa. brachten Verfügbarkeits-, Spoofing- und Delegationsrisiken. Selbst validiertes DNS authentisierte nicht automatisch die Anwendungsantwort, die Ressource oder die Aktualität einer Beschreibung.

Reguläre Ausdrücke mussten vor Ausführung geprüft werden. Eine authentische Regel konnte gefährlich bleiben, wenn sie ungeprüft an eine mächtige Umgebung ging. Herkunft und sichere Auslegung waren verschiedene Nachweise.

Der RFC Editor führt drei redaktionelle Errata. Die bestätigten Errata 282 und 787 korrigieren Verweise zur Additional-Information-Verarbeitung von RFC 3404 auf RFC 3403. Erratum 2923, zur Dokumentaktualisierung vorgemerkt, berichtigt Referenznummern in Abschnitt 4. Keines ändert Flags, Dienste oder Kardinalität.

Ein Betriebsbeleg sollte kanonische Eingabe, Schema oder Namensraum, ersten Schlüssel, DNS-Abfrage, vollständige NAPTR-Menge, Flag-Entscheidung, Protokoll, Dienst und Kardinalität, Auswahl im selben ORDER, gewählte Regel, Übergabe S/A/U/P, nächste Abfrage oder URI, Anfragekodierung, authentisierten Peer, Inhaltstyp, Objektklasse und konsumiertes Ergebnis bewahren.

Lu Hengs Prinzip der minimalen Anfangsspezifikation erklärt den Entwurf: gemeinsame Grenzen präzise normieren und besonderen Protokollen lokale Entwicklung lassen. Der Vorrang laufenden Codes liefert den Test: dieselbe Kennung nach Ort, Ressource und Beschreibung fragen; Additional entfernen; ein unbekanntes Flag einführen; Fähigkeiten im selben ORDER verändern. Nur vertraglich erlaubte Ergebnisse dürfen wechseln.

RFC 3404 versprach nicht jede Antwort für jede Kennung. Es verlangte, die gesuchte Antwort und die überschrittene Grenze zu benennen. So wurde „aufgelöst“ von einer leeren grünen Anzeige zu einer überprüfbaren Aussage.

Quellen