Zusammenfassung

  • Die „Beinahe-Byte-Kopie“ aus RFC 2159 bildete zusätzlich Parameter ab, kehrte die Bitreihenfolge um, füllte Seiten auf und setzte eine Grenze aus sechs EOL.
  • Der verlustfreie Rückweg hing von Seitengrenzen, abschließenden EOL und unbenannten DCS-Bits ab; ein gleicher Body-Hash bewies nicht dasselbe Faxobjekt.
  • Ein strukturell korrekter Rundlauf belegte weder Decoderunterstützung noch exakte Zeilengeometrie oder ein brauchbares Bild.

Beinahe bezeichnete die eigentliche Arbeit

RFC 2159 erschien im Januar 1998 und definierte, wie bereits als Gruppe-3-Fax codierte Daten in MIME getragen und nach X.400 abgebildet werden. image/g3fax sollte kein allgemeines Internet-Bildformat sein. Es ging darum, eine vorhandene Darstellung zwischen zwei Nachrichtensystemen rekonstruierbar zu halten.

Das Objekt bestand aus Codierungsoptionen, einer Seitenstruktur und den T.4-Bildbits je Seite. Optionen wurden MIME-Parameter. Die X.400-Folge von BIT STRINGs wurde ein fortlaufender Body mit Trennmuster. Für die Bilddaten galt eine andere Bitreihenfolge innerhalb des Bytes.

RFC 1494 hatte Byte Copy als Kopie ohne Umwandlung definiert. G3Fax trug schon dort das nearly. Das Bild musste nicht dekomprimiert und neu codiert, wohl aber seine Hülle neu gebaut werden.

Auch ein fehlender Parameter hatte Bedeutung

MIME konnte Seitenlänge und -breite, ein- oder zweidimensionale beziehungsweise unkomprimierte Codierung, feine oder grobe Auflösung, Seitenzahl und eine Base64 Device Control String tragen. Ohne Angaben galten A4, A4, eindimensional und grob. Abwesenheit wählte einen Wert.

Die Bitnummern derselben Option unterschieden sich in T.30 und X.400, weil beide vom entgegengesetzten Ende des Oktetts zählen. Das Gateway musste Bedeutung statt Nummer übertragen. Davon getrennt war das spätere Umkehren jedes Bytes der Seitendaten.

Für gesetzte Bits ohne benannte Option sollte DCS mitgegeben werden. Zugleich garantierte der RFC für diese NonBasicParameters keine Interoperabilität. Ein unbekanntes Bit zu bewahren erhielt den Befund, aber nicht die Fähigkeit des Empfängers.

Die Seitengrenze musste erzeugt werden

X.400 speicherte je Seite einen ASN.1 BIT STRING in einer Folge. MIME brauchte einen Body. RFC 2159 nahm sechs aufeinanderfolgende EOL als Grenze; ein EOL bestand aus elf Nullen und einer Eins. Die Folge musste auf einer Bytegrenze beginnen, daher waren Nullen als Padding nötig.

Das Muster lautete 00 10 01 00 10 01 00 10 01 und konnte dem RFC zufolge nicht im Bild vorkommen. So ließ sich die Seite ohne Rendering finden. Grenzposition, Ausrichtung und Paddinglänge wurden aber Teil des Nachweises. Ein abgeflachter Bitstrom bewies nicht dieselbe Seitenfolge.

Von X.400 nach MIME wurden abschließende EOL entfernt, die Bits auf die Internetreihenfolge gebracht, bis zur Bytegrenze aufgefüllt, sechs EOL angehängt und die Seiten verkettet. Auf dem Rückweg wurde an sechs EOL getrennt, die abschließenden EOL blieben erhalten, jedes Byte wurde umgekehrt und die ASN.1-Folge entstand neu.

Das Beibehalten der EOL war eine ausdrückliche Änderung gegenüber RFC 1494, die beim Rückweg EOL und Padding entfernt hatte. Die grobe Bezeichnung blieb gleich, die genaue Rückkehrregel nicht.

Ein Hash kennt die Bedeutung der Bitreihenfolge nicht

Ein stabiler MIME-Hash belegt, dass diese Oktette den beobachteten Abschnitt unverändert passiert haben. Er sagt nicht, ob das vorherige Gateway die richtige Reihenfolge verwendete. Gepackte BIT-STRING-Bytes und MIME-Bytes dürfen bei korrekter Abbildung verschieden sein, weil die Umkehr vorgeschrieben ist.

Ein sinnvoller Vergleich erfasst signifikante Bits je Seite, ungenutzte ASN.1-Bits, Reihenfolgeregel, Padding und Grenzpositionen. Auf dem Rückweg müssen Seiten, Nutzbits, Parameter und DCS wiederkehren.

RFC 2157 liefert den Maßstab: Equivalence sind zwei Mappings, die zusammen verlustfrei sind. Eine gültige Ausgabe in eine Richtung belegt nur einen Pfeil.

Umkehrbar bedeutete noch nicht darstellbar

Die Implementierungshinweise trennten Struktur und Nutzung. Ohne fineResolution waren Pixel doppelt so hoch wie breit. Manche Auflösungen und Längen waren leichter zu unterstützen als B4- oder A3-Breiten. Einige Faxgeräte hatten Probleme, wenn eine Zeile nicht exakt die deklarierte Pixelzahl enthielt, etwa nach Weglassen des rechten Weißraums.

Ein Gateway kann Seiten und Optionen wiederherstellen, während der Decoder den Modus nicht unterstützt. Er kann Daten akzeptieren und die Geometrie verzerren. Eine plausible Seite kann abgeschnitten sein. Syntax, Rekonstruktion, Maße, Bildtreue und menschliche Nutzung sind getrennte Beobachtungen.

Die heutige IANA-Liste führt image/g3fax; die historischen MIME/X.400-Tabellen ordnen es g3-facsimile zu. Das belegt einen öffentlichen Namen, nicht eine Produktimplementierung oder Empfängerfähigkeit.

Ein belastbarer Test beginnt mit X.400-Parametern, DCS, Seiten, Bitlängen, Fingerprints und Gateway-Version. Auf MIME-Seite hält er Parameter, Padding und Grenzen fest. Der Rückweg vergleicht die wiederhergestellte Folge. Erst danach folgen Modi, Pixel je Zeile, Maße und Rendering.

Lu Hengs Texte zu laufendem Code, minimaler Spezifikation und Realitätsebenen dienen als offengelegte Linse: Regel, Ausführung, Darstellung und Ergebnis leihen einander keinen Beweis.

Das nearly aus RFC 2159 war eine Liste dessen, was außerhalb der Kopie lag. Ohne Optionen, Seiten, Reihenfolge, Padding oder Empfängerfähigkeit kann ein intakter Body aufhören, das ursprüngliche Fax zu sein.

Quellen