Zusammenfassung

  • RFC 3966 verglich tel-URIs ohne visuelle Trenner, Groß-/Kleinschreibung und textuelle Parameterreihenfolge, hielt aber Lokal-/Globalform, phone-context und jeden Parameternamen für wesentlich.
  • Gleichheit bezeichnete nur dieselbe Ressource im Rahmen dieses Identifikatorvertrags; sie bestätigte keine aktuelle Zuteilung, Erreichbarkeit, Route, Person, Einwilligung oder Gesprächsleistung.

Telefonnummern sind zugleich maschinenlesbare Werte und menschliche Schreibobjekte. Menschen gruppieren Ziffern, setzen Klammern und passen die Darstellung an örtliche Gewohnheiten an. Ein reiner Bytevergleich macht daraus falsche Duplikate. Eine Bereinigung, die alles außer Ziffern entfernt, verschmilzt dagegen womöglich getrennte Nummernräume. Der im Dezember 2004 veröffentlichte RFC 3966 bestimmte deshalb nicht nur eine Syntax, sondern eine gezielte Gleichheitsrelation.

Ein tel-URI benannte eine durch eine Telefonnummer identifizierte Ressource. Er war keine Wählanweisung. Amtskennziffer, internationale Verkehrsausscheidungsziffer, Ton- oder Impulswahl, Interpretation von Rufzeichen und Nachwahlhandlungen blieben lokaler Konfiguration überlassen. Ebenso wenig stand der URI zwingend für ein bestimmtes physisches Telefon. Eine Nummer konnte feste, mobile oder nomadische Endpunkte und Sprach-, Daten-, Fax- oder andere Dienste erreichen.

Gegenüber RFC 2806 wurde diese Trennung strenger. RFC 3966 entfernte Betreiberauswahl, Wählkontextaktionen, Fax- und Modem-URI-Formen, Pausen sowie Nachwahlzeichen aus dem Schema. Die Identität blieb, die Handlungsanweisung ging. RFC 3601 dokumentiert die benachbarte Geschichte aktionshaltiger Telefonzeichenfolgen, nicht die hier untersuchte Gleichheit.

Gleichheit durch begrenztes Vergessen

Beim Vergleich der Rufnummer entfernte ein Parser die visuellen Trenner , ., ( und ). Groß- und Kleinschreibung waren gleichwertig. Parameter wurden anhand ihres Namens zusammengeführt, unabhängig von ihrer Reihenfolge im empfangenen Text. Zwei globale oder zwei lokale URIs konnten damit trotz unterschiedlicher Darstellung gleich sein.

Die Normierung durfte aber nicht jedes Hindernis wegräumen. Beide Seiten mussten entweder lokal oder global sein. Eine lokale und eine globale Form blieben unter dem Algorithmus ungleich, selbst wenn betriebliches Wissen denselben erreichbaren Anschluss vermutete. Kam ein Parametername nur auf einer Seite vor, war das Paar ungleich. Bei lokalen Nummern gehörten phone-context, Nebenstelle, ISDN-Subadresse und verpflichtende Erweiterungen zur Identität.

Die Grammatik empfahl außerdem eine kanonische Reihenfolge: zunächst isub oder ext, danach phone-context, anschließend weitere Parameter lexikalisch sortiert. Das half Systemen, die weiterhin Zeichen verglichen. Die semantische Regel ordnete empfangene Parameter dennoch nach Namen zu. Ein stabil serialisierter Text und ein korrektes Gleichheitsurteil waren zwei getrennte Kontrollen.

RFC 3986 lieferte später den allgemeinen URI-Rahmen. RFC 3261 verwendete Telefonteilnehmer-Syntax in SIP und machte sichtbar, wo umgebende Systeme weiterhin zeichenempfindlich waren. Eine prüfbare Implementierung bewahrt daher Originaltext, geparste Struktur, jeden Normalisierungsschritt und die kanonische Ausgabe getrennt. Sie ersetzt das Eingangsdokument nicht durch sein Derivat.

Kontext erzeugte Eindeutigkeit, aber keine Route

RFC 3966 bevorzugte globale Nummern. Private Nebenstellen, Notrufcodes und andere lokale Dienste ließen sich jedoch nicht immer global ausdrücken. Eine lokale Nummer brauchte deshalb phone-context: einen kontrollierten Domainnamen oder die führenden Ziffern einer gültigen globalen Nummer. Lokale Ziffern und Kontext sollten zusammen einen weltweit eindeutigen Identifikator bilden.

Der Kontext war kein Präfix zum Ankleben. Aus 911 und phone-context=+1 wurde nicht +1-911. Ein Domainkontext musste nicht einmal zu einem Host auflösbar sein; er musste unter der administrativen Kontrolle des Verwalters dieses lokalen Nummernraums stehen. Kontextgleichheit bewies deshalb weder ein DNS-Gateway noch eine aktive Route, gültige Zuteilung oder Nutzungsberechtigung.

Wer den URI nur als Bezeichner verwendete, konnte den Kontext als undurchsichtigen Wert behandeln. Wer wählen wollte, musste ihn verstehen und darin operieren können. Selbst eine globale Nummer konnte laut Spezifikation veraltet oder von einem Ort aus unerreichbar sein. Ressourcengleichheit und Handlungsfähigkeit benötigten voneinander unabhängige Nachweise.

Ein gleiches Parameterset konnte unbrauchbar bleiben

ext kennzeichnete eine Nebenstelle hinter einer Nicht-ISDN-Telefonanlage, isub eine ISDN-Subadresse; beide durften nicht zusammen vorkommen. RFC 4715 verfeinerte später die Kodierung von ISDN-Subadressen. RFC 4694, RFC 4759 und RFC 4904 erweiterten die Parameterhistorie um Nummernportierung, ENUM-Abfragen und Leitungsgruppen.

Für künftige verpflichtende Parameter reservierte RFC 3966 das Präfix m-. Traf eine Implementierung auf einen unbekannten Pflichtparameter, durfte sie den URI nicht verwenden; unbekannte optionale Parameter konnten ignoriert werden. Daraus folgten zwei Prüfungen: Stimmen die strukturierten Bezeichner überein? Darf und kann der Empfänger handeln? Auch ein auf beiden Seiten gleich vorhandenes, unbekanntes m- verleiht dem Empfänger kein Verständnis.

RFC 5341 führte später das Registrierungsverfahren für tel-URI-Parameter ein. Das heutige IANA-Register der tel-URI-Parameter veröffentlicht das koordinierte Vokabular. Ein eingetragener Name ist auffindbar; dadurch werden ein konkreter Wert, seine Aktualität, die Behauptungsbefugnis des Absenders oder die Fähigkeit des Empfängers nicht bestätigt. Gleichheit, Gültigkeit, Fähigkeit und Autorität bleiben getrennt.

Eine Telefonressource war keine Personenidentität

Während des Rufaufbaus konnte derselbe tel-URI in mehrere andere URIs übersetzt werden. Signalisierung handelte den Dienst aus; ein Endpunkt konnte mehrere Identifikatoren haben, und eine Nummer musste weder ein einziges Gerät noch einen einzigen Menschen auswählen. RFC 6116 beschrieb später die ENUM-Auflösung von E.164-Nummern zu Diensten und URIs. Sie erzeugt einen zusätzlichen Beleg über Antworten und Zeitpunkt, erhebt aber das Gleichheitsergebnis von RFC 3966 nicht zur Identitätsprüfung des Gesprächspartners.

Auch die Sicherheitsbetrachtung hielt diese Grenze ein. Ein Webclient sollte einen tel-Link nicht ohne ausdrückliche Zustimmung anwählen. Der Ruf konnte Geld kosten, eine Leitung belegen, Anruferdaten offenlegen oder missbräuchlich sein. Der sichtbare Linktext konnte sogar eine andere Nummer zeigen als das Ziel. Gleichheit zweier geparster Ziele sagte weder, dass die Darstellung ehrlich war, noch dass ein Mensch zugestimmt hatte.

Die Informationsseite des RFC Editors, die Errata-Suche und der Datatracker-Eintrag der IETF belegen Status und gemeldete Korrekturen. Sie liefern keine Adoptionsquote, Kollisionsfälle oder Gesprächsergebnisse. Für eine Revision sollten Originalbytes und Anzeige, lokale/globale Form, Ziffern vor und nach Trennerentfernung, Fallumwandlung, Parametersatz und Empfangsreihenfolge, kanonische Reihenfolge, Kontextart und -verwalter, Nebenstelle oder Subadresse, Pflichtparametererkennung, Parserfassung, Vergleichsregel und Ergebnis erhalten bleiben. Zuteilungsfrische, Wählumwandlung, Signalisierungsziel, Route, Zustimmung, Antwort, menschliche Annahme, Dienst und Kosten brauchen eigene Belege.

RFC 3966 machte den Vergleich brauchbar, indem er nur Unterschiede vergaß, die der Vertrag als Darstellung einstufte. Seine Gegenregel ist ebenso wichtig: Was der Vergleich nicht beobachtet, darf nicht unbemerkt in das Wort „gleich“ hineininterpretiert werden.

Quellen