Zusammenfassung

  • RFC 3968 ergänzte das in RFC 3261 fehlende IANA-Register für SIP-Headerfeldparameter und -werte und band Namen an Feldkontext und definierende RFCs.
  • Die Registrierung schützte eine öffentliche Bedeutungszuordnung. Sie bewies weder Implementierung noch Verständnis, Verhandlung, Autorisierung, sichere Nutzung oder Gesprächserfolg.

Ein Präfix kann wie ein Etikett für den Lebenszyklus wirken. P- klingt vorläufig oder privat, X- experimentell, ein Name ohne Zusatz standardisiert. Doch Buchstaben reisen mit Paketen, während der ursprüngliche Geltungsbereich, die Reviewgeschichte und die installierte Basis sich verändern. Genau diese Trennung erklärt, warum ein ausdrückliches Register dauerhafter ist als eine Benennungskonvention.

RFC 3968 schloss zunächst eine konkrete Lücke. RFC 3261 erlaubte neue Parameter und Parameterwerte in SIP-Headerfeldern, hatte aber kein IANA-Register dafür eingerichtet. Unabhängige Entwickler konnten denselben kurzen Namen für unvereinbare Funktionen wählen.

Die neue Registrierung musste Headerfeld, Parametername, einen Hinweis auf vordefinierte Werte und die definierenden RFCs enthalten. Diese RFCs mussten Syntax, Verwendungszweck und Semantik vollständig erklären. Der erklärte Zweck war Interoperabilität zwischen unabhängigen Implementierungen und die Vermeidung zufälliger Namenskollisionen.

Explizite Metadaten ersetzten Namensmagie

RFC 3427 versuchte, vorläufige, private oder proprietäre SIP-Header mit P- zu kennzeichnen und durch Review einzugrenzen. Hintergrund waren Erweiterungen, die Sicherheit beschädigen oder die Protokollkomplexität stark erhöhen konnten.

Das Präfix hielt die Grenze nicht. RFC 5727 berichtete, dass manche P--Header außerhalb ihrer vorgesehenen geschlossenen Umgebung breite Verwendung fanden. Sobald eine große installierte Basis existierte, gab es keinen plausiblen Migrationspfad zu einem anderen Namen. Der Sonderprozess wurde aufgegeben.

RFC 6648 verallgemeinerte diese Erfahrung. Implementierungen dürfen aus X- oder seinem Fehlen weder Standardisierungsstatus noch Sicherheit ableiten. Ein Namensbestandteil ist kein verlässliches Zustandsfeld.

RFC 3968 setzte stattdessen auf getrennte Daten: Name, Kontext, Referenz und Registrierungspolitik. Diese Angaben lassen sich ändern und prüfen, ohne die Protokollzeichenfolge als Geschichtsspeicher zu missbrauchen.

Ein gleicher String konnte ein anderes Objekt sein

Parameter durften in verschiedenen Headerfeldern denselben Namen tragen. Innerhalb desselben Feldes mussten Namen eindeutig sein. Der Feldname gehörte somit zur Identität.

Wer in Telemetrie nur q, tag oder algorithm speichert, kann eine exakte Zeichenfolge finden und dennoch die falsche Semantik zuordnen. Ein belastbarer Datensatz bewahrt Headerfeld, Parameter, Referenzmenge und Beobachtungszeit.

Registrierte Namen galten als reserviert und mussten im Sinn ihrer RFC verwendet werden. Lokale Definitionen durften nicht kollidieren. Unregistrierte Parameter waren nicht generell verboten, aber riskant: Eine spätere Registrierung konnte denselben Namen öffentlich anders binden. Ein funktionierender privater Austausch war lokaler Konsens, keine globale Reservierung.

Der Verweis war Teil der Bedeutung

Die Spalte Predefined Values war keine Werteliste. Bei Yes mussten Implementierer die zitierten RFCs aufsuchen. RFC 3968 registrierte Werte per Referenz und fügte spätere Dokumente mit neuen Werten in doppelten Klammern hinzu.

Eine kopierte Tabelle konnte damit offiziell aussehen und trotzdem unvollständig sein. Ohne Referenzen fehlten Grammatik, Bedingungen, Semantik und Sicherheitsbetrachtung. Ohne Zeitstempel konnte eine alte Kopie neue zulässige Werte zurückweisen.

Die Registrierungspolitik hieß nach RFC 2434 IETF Consensus; eine RFC war erforderlich, aber nicht zwingend Standards Track. RFC 8126 fasste Registrierung später als Bindung eines Werts an einen Zweck in einem Namensraum. Diese Bindung verteilt Namensautorität, nicht Software.

Laufzeitunterstützung hatte eigene Belege

RFC 3261 definierte Supported, Require, Proxy-Require, Unsupported und die Antwort 420. Ein Endpunkt konnte Unterstützung behaupten, Verständnis verlangen oder nicht unterstützte Anforderungen nennen. Solche Signale entstanden in einer konkreten Transaktion.

Ein IANA-Eintrag erzeugte sie nicht. Er nannte keine Programmversion, kein aktiviertes Modul und keine Zulassungspolitik. Selbst eine Supported-Angabe war noch kein Beweis, dass eine bestimmte Anfrage akzeptiert oder erfolgreich abgeschlossen wurde.

Unbekannte, für die Anfrage nicht notwendige Headerfelder sollte ein Server ignorieren und weiterarbeiten. Eine durchgelaufene Nachricht konnte daher verstandene Verarbeitung oder bewusstes Nichtverstehen bedeuten. Paketüberleben und semantische Wirkung waren getrennt.

Die Ausgangstabelle verband sehr unterschiedliche Quellen. RFC 3310 behandelte Digest-Authentisierung, RFC 3265 Ereignisse, RFC 3455 Erweiterungen für private Netze und RFC 3329 Sicherheitsvereinbarungen. Gleiche Spalten machten sie auffindbar, nicht funktional gleich.

Das heutige IANA-Register der SIP-Parameter ist ein lebender Verbund vieler Teilregister. RFC-Editor-Eintrag, Errata und IETF Datatracker belegen Dokumentstatus, nicht Verbreitung oder Sicherheitswirkung.

RFC 3968 machte einen Namen im richtigen Kontext zurechenbar. Was ein Endpunkt damit tat, blieb eine eigene Beobachtung.

Quellen