Zusammenfassung

  • RFC 3969 reservierte jeden URI-Parameternamen in SIP und SIPS, damit dieselbe Schreibweise nicht zwei Bedeutungen erhielt; über die Anwendbarkeit entschied weiterhin der definierende RFC.
  • Der Text nannte „Specification Required“, verlangte aber einen Standards-Track-RFC. RFC 5727 bezeichnete dies als Widerspruch und stellte Standards Action als beabsichtigte Regel klar.

RFC 3969 erzeugte absichtlich eine Tabelle, die breiter aussah als das Verhalten dahinter. Jeder Parametername wurde sowohl für SIP- als auch für SIPS-URIs eingetragen. Zugleich warnte der Text, dass ein Parameter für eines der Schemata unpassend sein könne. Der zweite Eintrag sperrte den Namen; er schaltete keine Funktion frei.

RFC 3261 hatte neue Parameter und Werte erlaubt, aber kein IANA-Register dafür eingerichtet. Zwei unabhängige Erweiterungen konnten deshalb dasselbe Wort wählen und unterschiedlich deuten. Im Dezember 2004 schuf RFC 3969 die fehlende Koordinationsfläche.

Zwei Reservierungen hielten eine Bedeutung zusammen

Die Anfangstabelle enthielt comp, lr, maddr, method, transport, ttl und user. comp verwies auf RFC 3486, die übrigen zunächst auf RFC 3261. Eine Zeile enthielt Name, Kennzeichen für vordefinierte Werte und Referenzen.

Ein Yes war keine vollständige Werteliste. Die Spezifikationen mussten über sämtliche Verweise gelesen werden. Im heutigen IANA-SIP-Register verweist transport auf RFC 3261 und RFC 7118. Die Zeile ist somit ein lebender Quellenindex, kein eingefrorener Parser.

Registrierte Namen galten als reservierte Wörter. Lokale, nicht registrierte Namen blieben möglich, konnten aber mit einer späteren öffentlichen Zuweisung kollidieren. Einen Herstellerbaum gab es nicht. RFC 3427 hatte vor Sicherheitsfolgen und wachsender Komplexität durch SIP-Erweiterungen gewarnt; deshalb musste eine RFC Syntax, Zweck und Semantik erklären.

Der Eintrag blieb dennoch schmaler als die Ausführung. RFC 5630 erläuterte später SIPS-Behandlung und Sicherheitsanforderungen; RFC 3263 Serverermittlung und Transportwahl. Eine doppelte Namensreservierung beweist keine dieser Bedingungen und auch keine Produktunterstützung.

Die Zulassungsregel widersprach ihrem Etikett

Abschnitt 4.2 übernahm aus RFC 2434 die Bezeichnung „Specification Required“. Direkt danach verlangte er jedoch einen Standards-Track-RFC. Beide Verfahren verteilen Prüfung und Entscheidung unterschiedlich.

RFC 5727 hielt 2010 fest, dass dieser Widerspruch aus einem Missverständnis der Kategorien entstand und Standards Action beabsichtigt war. So lautet heute auch die IANA-Regel. RFC 8126 aktualisierte später das Vokabular und macht sichtbar: Solche Etiketten sind Zugriffsregeln für einen Namensraum.

Der aktuelle Stand darf die Herkunft nicht überschreiben. RFC-Editor-Eintrag, Errata-Suche und IETF Datatracker belegen Status, gemeldete Korrekturen und Verlauf. RFC 3986 liefert den URI-Rahmen; RFC 6648 warnt später davor, Reife oder Sicherheit aus Namenspräfixen abzuleiten.

Bei einer Beobachtung sind Schema, Schreibweise und Zeitpunkt zuerst zu sichern. Danach folgt man allen Referenzen, prüft Anwendbarkeit und Sicherheit und erhebt erst dann Nachweise zu Softwareversion, Konfiguration, Transaktion und Ergebnis. Ein erfolgreicher Anruf kann den Parameter ignoriert haben; ein registrierter Name kann auf unbekannte Software treffen.

RFC 3969 reservierte weit, damit Bedeutungen nicht auseinanderliefen. Aus dieser Vorsicht darf keine breite Verhaltensbehauptung werden. Zwei geschützte Plätze ergeben eine Identität, nicht zwei Fähigkeitsnachweise.

Quellen