Zusammenfassung

  • RFC 3368 gab go: zwei Aufgaben: einen bestimmten CNRP-Dienst anzusprechen oder eine Namensanfrage an die vom Client ausgewählten Dienste zu geben.
  • Ein servergebundener id=-Link konnte einen Datensatz bezeichnen, ohne den Namen mitzuschicken, den Leser darin zu erkennen glaubten. Syntax, Registrierung und Auflösung waren verschiedene Belege.

Im August 2002 entwarf RFC 3368 einen Link für ein Problem, das gewöhnliche Webadressen nur unzureichend lösten: Menschen merken sich Namen, während Netze Ressourcen über Kennungen und Dienste adressieren. Das Schema go: verlieh dem Namen selbst keine Autorität. Es beschrieb, wie ein Client eine CNRP-Anfrage zu einem Dienst transportieren sollte.

Der Unterschied steht direkt hinter dem Doppelpunkt. go://cnrp.example?Ada%20Lovelace nennt einen bestimmten Server und richtet eine Anfrage an ihn. go:Ada%20Lovelace enthält keinen Server; RFC 3368 sah diese Form für einen oder mehrere CNRP-Dienste vor, die im Client bereits eingerichtet waren. Derselbe sichtbare Name konnte daher auf verschiedenen Geräten bei unterschiedlichen Diensten landen. Der Link brachte kein weltweit einheitliches Resolververzeichnis mit.

Eine URI mit ausschließlich einem Server bekam in RFC 3368 eine weitere Bedeutung: Sie identifizierte einen CNRP-Dienst, nicht eine bestimmte Abfrage. Der Client konnte dessen Fähigkeiten per servicequery erfragen. Ein leerer Serverwert bedeutete localhost; ohne anderes Vorwissen über Transportwege sollte HTTP über Port 1096 verwendet werden. Diese Vorgaben erleichterten den Gesprächsbeginn. Sie belegten weder Erreichbarkeit noch Vertrauenswürdigkeit noch aktuellen Betrieb.

Die Kürze war beabsichtigt. CNRP konnte Anfragen als XML ausdrücken, doch komplexes XML hätte die URI-Längenbegrenzung schnell gesprengt. RFC 3368 legte deshalb eine kleinere Syntax für Namen und Attribut-Wert-Paare fest. Sie verwendete UTF-8 und Prozentkodierung für Zeichen außerhalb der Grammatik; das Beispiel kodiert ü als UTF-8-Bytes. Die verkürzten Schreibweisen im Fließtext dienen nur der Erläuterung; maßgeblich ist die ABNF.

Der wichtigere Grenzfall lautete go://cnrp.example?id=5432345. Diese URI verwies auf einen bestimmten Datensatz bei einem bestimmten Server, enthielt aber keinen geläufigen Namen. RFC 3368 warnte im Sicherheitsabschnitt vor der Lücke: Eine Person könnte glauben, der Link zeige auf die Ressource, die gerade dem Namen „BMW“ zugeordnet ist, obwohl „BMW“ gar nicht in der URI vorkommt. Eine maschinenlesbare Kennung kann stabil und für den Menschen, der ihr vertrauen soll, trotzdem undurchsichtig sein.

RFC 3367, das zugehörige Protokoll, nahm Ermittlung und Auswahl von Dienstanbietern, Namensregistrierung, Eigentum und Eindeutigkeit zunächst aus dem Umfang. Die im Client eingerichtete Dienstauswahl von RFC 3368 blieb damit lokal; sie entschied nicht weltweit, wer für einen Namen sprechen durfte. Später führte das IANA-Register für URI-Schemata go als Permanent mit RFC 3368 als Referenz. Das belegt den Registrierungsstatus, nicht Browserunterstützung, aktive Dienste, Datenverkehr oder Verbreitung.

Die historische Trennlinie ist einfach: Ein Link kann einen Dienst, eine Anfrage oder einen Datensatz identifizieren, aber diese Dinge sind nicht austauschbar. Heng Lus „Reality Layers“ und „Running-Code Primacy“ werden hier als offengelegte redaktionelle Blickwinkel verwendet, um Syntax, registrierten Entwurf und beobachteten Betrieb auseinanderzuhalten. Sie sind weder Protokollanforderungen noch Beleg für den Einsatz von go:.

Quellen