Zusammenfassung

  • RFC 3362 registrierte image/t38 als SDP-Medienbezeichner für einen Echtzeit-Faxstrom; die Kodierung selbst blieb in der ITU-T-Empfehlung T.38 definiert.
  • Das Label beseitigte eine Namensmehrdeutigkeit, bewies aber weder Annahme im Offer/Answer-Verfahren noch Transport, Verschlüsselung, Gateway-Umsetzung oder vollständigen Seitenempfang.

Wenn ein Parser image/t38 erkennt, ist genau eine Frage beantwortet: Welche Art von Medienstrom beschreibt die Gegenstelle? Ob sie denselben Strom akzeptiert, ob Pakete ankommen und ob am Ende eine vollständige Seite entsteht, steht noch offen.

RFC 3362 erschien 2002 an einer Schnittstelle verschiedener Normungswelten. ITU-T T.38 beschrieb die technischen Eigenschaften für Echtzeitkommunikation zwischen Gruppe-3-Faxgeräten oder Gateways über IP-Netze. SIP und SDP lieferten Verfahren für Sitzung und Beschreibung. Der RFC registrierte einen gemeinsamen Namen, damit SDP auf diesen T.38-Strom verweisen konnte.

Die Kodierung wurde nicht in den RFC verlagert. Der Text verwies ausdrücklich auf T.38. Er hielt außerdem fest, dass je nach Dienstumgebung TCP oder UDP eingesetzt werden konnte. Die in Annex D beschriebenen SIP/SDP-Verfahren ließen sich nach der ursprünglichen SIP-Fassung auch mit der überarbeiteten RFC 3261 anwenden.

Diese Aufgabenteilung war keine Lücke. Sie machte Standards kombinierbar. ITU-T definierte Faxverhalten, das IETF Sitzungsmechanik, IANA den beständigen Bezeichner. Implementierer entschieden über die Übernahme, Betreiber über die Konfiguration und Beobachtung. Kein Register musste so tun, als betreibe es den Dienst.

Der Registrierungseintrag war knapp: keine Pflichtparameter, keine optionalen Parameter, binäre Kodierung, vorgesehene Nutzung common. Gerade das Fehlen von Parametern setzte eine Grenze. Das Label trug kein verborgenes vollständiges Kompatibilitätsprofil. Weitere Entscheidungen gehörten in T.38, SDP, SIP und die laufenden Systeme.

Auch der Nutzungskontext war begrenzt. image/t38 war als Kennzeichnung eines T.38-Stroms in SDP gedacht, nicht für E-Mail. Eine E-Mail-Verwendung war nicht definiert und deshalb nicht als interoperabel mit einem T.38-Strom garantiert. Der Obertyp image verwandelte eine Echtzeitsitzung nicht in einen gewöhnlichen Anhang.

Die Sicherheitsangabe blieb ebenso präzise. Der Inhalt bezeichnete einen Fax-Bitstrom, der verschlüsselt sein konnte oder nicht. Aus dem Label folgte keine Vertraulichkeit. Es sagte nichts darüber, ob SIP geschützt war, ob der Medientransport verschlüsselt wurde oder ob ein Gateway an anderer Stelle Klartext erzeugte.

SDP selbst war nur Beschreibung. RFC 2327, RFC 4566 und der heutige RFC 8866 erklären, dass SDP ein Sitzungsbeschreibungsformat ist und kein Transportprotokoll enthält. Adresse, Port, Medium und Format können beschrieben werden; die Beschreibung befördert kein Paket.

Danach musste die Gegenstelle antworten. RFC 3264 modelliert den Wunsch der einen Seite als Offer und die Sicht der anderen als Answer. Erst beide ergeben das vollständige Bild. Eine Answer darf einen Medienstrom durch Port null ablehnen. Ein gültiges image/t38 im Offer beweist deshalb nur den Vorschlag.

Auch die Annahme beendet die Prüfung nicht. Beide Seiten müssen kompatibles T.38-Verhalten ausführen. Der gewählte Transport muss den Netzpfad überstehen. Verlust, Verzögerung und Umordnung dürfen die Grenzen nicht überschreiten. Gateways müssen Paketabläufe in das Zeitverhalten von Faxgeräten übersetzen. Eine aufgebaute Sitzung kann mit einer abgebrochenen Seite enden.

Ein belastbares Beweisbuch trennt diese Stufen. Der IANA-Eintrag beweist Registrierung und Referenz. Ein Softwareinventar kann Erkennung belegen. Das Offer belegt Vorschlag, die Answer Annahme oder Ablehnung. Paketspuren belegen beobachteten Transport. Gateway-Ereignisse belegen Umsetzungsversuche. Seitenzähler und Abschlussmeldungen belegen technische Fertigstellung. Der geschäftliche Empfang folgt erst danach.

Diese Nachweise sind nicht austauschbar. Registrierung ist keine Verbreitungsmessung. Erkennung ist keine Annahme. Annahme ist kein Transport. Transport ist keine vollständige, lesbare und bearbeitete Seite.

Die Registrierungsregeln entwickelten sich weiter. RFC 2048 war zur Zeit von RFC 3362 maßgeblich; RFC 4288 und RFC 6838 überarbeiteten den allgemeinen Rahmen. Prüfung, Eindeutigkeit und Stabilität verbessern die gemeinsame Referenz. Sie installieren keine Funktion auf einem Gateway.

Dasselbe gilt für RFC 2119 und RFC 8174. Normative Schlüsselwörter geben an, was eine konforme Implementierung tun soll. Sie sind kein Auditprotokoll einer bestimmten Maschine. Zwischen Muss-Satz und Betriebsfakt liegt eine Messung.

Der heutige IANA-Datensatz bewahrt image/t38 und den Verweis auf RFC 3362. Das ist wertvolle Registerkontinuität. Daraus lassen sich aber weder Anzahl aktiver Gateways noch Transportwahl, Verschlüsselung oder Erfolgsquote ableiten.

Zwei Texte von Lu Heng dienen als offengelegte Analyserahmen. „Minimum Initial Specification“ plädiert für eine schmale gemeinsame Schicht aus notwendigen, lokal prüfbaren Regeln und für Adoption durch tatsächlich laufenden Code. Der knappe RFC zeigt den Nutzen dieses Prinzips. „On Reality Layers“ trennt symbolische Einträge von betrieblicher Wirklichkeit. Registrierung, Angebot, Annahme, Transport und Seite sind hier verschiedene Ebenen.

RFC 3362 war erfolgreich, weil er nicht mehr behauptete, als er koordinierte. Das Label benannte den Strom. Für jede Aussage über dessen Funktion musste ein weiterer Beleg folgen.

Quellen