Zusammenfassung

  • RFC 2158 verband JPEG und GIF über Body-Part-Namen, OIDs, MIME-Typen und unverändert übertragene Oktette; diese Merkmale gehören zusammen, sind aber nicht austauschbar.
  • Im Abschnitt FTAM EMA GIF steht image/jpeg, obwohl Überschrift, Body-Part-Name und OID gif-image(4) auf GIF verweisen.
  • Der Kontext spricht stark für einen Kopierfehler, doch der RFC Editor führt derzeit kein Erratum zu RFC 2158; weder die wahrscheinliche Absicht noch das gedruckte Etikett belegen, was ein eingesetztes Gateway tatsächlich ausgegeben hat.

Ein Eintrag zerbrach seine eigene Identitätskette

RFC 2158 erschien im Januar 1998 und beschrieb zwei kurze Pfade für Bilder zwischen MIME und X.400. Als Extended Body Parts definierte sie mime-jpeg-body unter { mixer-bp-data 3 } und mime-gif-body unter { mixer-bp-data 4 }, jeweils ohne Parameter. Hinzu kamen zwei FTAM-Anlagenkennungen der Electronic Messaging Association.

Drei der vier Fälle folgen einem klaren Muster: JPEG Extended Body Part mit image/jpeg; FTAM EMA JPEG ebenfalls mit image/jpeg und einer OID auf jpeg-image(6); GIF Extended Body Part mit image/gif. Der vierte Abschnitt heißt „image/gif - FTAM EMA GIF“, nennt den Body Part FTAM EMA GIF und zeigt einen OID-Pfad bis gif-image(4). Dazwischen steht jedoch MIME Content-Type: image/jpeg; der nächste Satz bezeichnet die OID als JPEG zugewiesen.

Der Widerspruch steckt also in einem einzigen kompakten Eintrag. Drei Identifikatoren sagen GIF, ein Feld und ein offenbar mitkopiertes Substantiv sagen JPEG. Sie können nicht gleichzeitig dasselbe Format beschreiben.

„Keine Konvertierung“ erhöhte die Tragweite

Jede Zuordnung trägt Conversion: None. Das Gateway sollte nicht ein Rasterformat dekodieren und in ein anderes umwandeln. Es verband eine X.400-Repräsentation mit einem MIME-Typ und übernahm die Oktette unverändert. Ein JPEG-Header macht GIF-Bytes daher nicht zu JPEG; ein GIF benannter OID-Zweig macht JPEG-Bytes nicht zu GIF.

RFC 2046 zieht die entscheidende Grenze: Unter dem Haupttyp image bezeichnet der Subtyp das konkrete Bildformat. Im IANA-Register der Medientypen sind image/gif und image/jpeg getrennte Einträge. Ein Empfänger kann damit den Decoder wählen, doch das Etikett bleibt eine Behauptung über die Oktette. Richtige Regelwahl, unveränderter Hash und erfolgreiche Dekodierung sind getrennte Beobachtungen.

Die begleitende RFC 2157 stützt das Muster: Ihre Tabellen ordnen mime-jpeg-body image/jpeg und mime-gif-body image/gif zu. Das berichtigt RFC 2158 nicht stillschweigend, zeigt aber, warum Implementierende mehrere Felder abgleichen mussten.

Die naheliegende Berichtigung bleibt eine Schlussfolgerung

Am besten belegt ist die Lesart, dass der FTAM-EMA-GIF-Abschnitt image/gif und eine GIF zugewiesene OID nennen sollte. Dafür sprechen Überschrift, Body-Part-Name, OID-Blatt und Nachbareinträge. Der frühere MIXER-Entwurf verbindet den GIF Extended Body Part ebenfalls mit image/gif; er entstand jedoch vor den FTAM-Abschnitten und enthält keine berichtigte Fassung der strittigen Zeile.

Weiter reicht die Aktenlage nicht. Die Errata-Suche des RFC Editor liefert derzeit keinen Treffer für RFC 2158. „Wahrscheinlicher Redaktionsfehler“ ist eine begründete Analyse; „offiziell korrigiert“ wäre falsch.

Auch der Einsatz lässt sich daraus nicht ableiten. Ein Anbieter könnte dem MIME-Feld wörtlich gefolgt sein, Überschrift und OID bevorzugt, privat korrigiert, Dateisignaturen geprüft oder den FTAM-Pfad nie implementiert haben.

Die Spezifikation kann nicht für laufende Software aussagen

Für einen Verhaltensnachweis braucht man Tabellenversion, gewählte X.400-Kennung, vollständige OID, MIME-Feld und Bytes am Eingang, Ausgangsfelder und -bytes, gewählten Handler und Dekodierergebnis. Ein gleicher Hash belegt Bytekontinuität im beobachteten Schritt, nicht die Richtigkeit des Etiketts. Eine sichtbare Grafik belegt, dass ein Handler sie annahm, nicht dass alle Empfänger gleich entscheiden.

Dokument, Implementierung und beobachtetes Ergebnis sind eigene Beweisebenen. Sie können übereinstimmen, aber keine darf den Beleg der anderen übernehmen. RFC 2158 lehrt nicht, Etiketten zu verwerfen. Formatidentität ist eine zusammengesetzte Behauptung; bei Widerspruch darf das Etikett erst nach der Abstimmung von Bytes, Kennung und Code für das Ganze sprechen.

Quellen