要約

  • RFC 2158 は本文部名、OID、MIME Content-Type、変換されないオクテットを組み合わせて JPEG と GIF を識別した。
  • FTAM EMA GIF の節では、見出し、本文部名、gif-image(4) が GIF を示す一方、Content-Type は image/jpeg と記されている。
  • 文脈から誤植の可能性は高いが、RFC Editor の現行検索には RFC 2158 の erratum がない。推定上の修正も、稼働ゲートウェイの動作証明にはならない。

一つの項目に二つの形式が入った

1998 年1月の RFC 2158 は、MIME で定義された画像形式を X.400 で運ぶための小さな仕様である。JPEG には OCTET STRING の mime-jpeg-body と { mixer-bp-data 3 }、GIF には mime-gif-body と { mixer-bp-data 4 } を割り当てた。どちらにもパラメータはなく、内容は MIME の定義に従う。

等価関係の一覧では、JPEG Extended Body Part と FTAM EMA JPEG がそれぞれ image/jpeg に結び付けられ、後者の OID は jpeg-image(6) で終わる。GIF Extended Body Part は image/gif である。ところが第3.4節は、見出しも X.400 本文部も FTAM EMA GIF、OID も gif-image(4) でありながら、MIME 行だけを image/jpeg とした。続く文もその OID を JPEG 用と呼んでいる。

これは単一の項目内の衝突である。発行文が何を印刷したかは確定しているが、すべての識別子が同時に正しいとは言えない。

バイトを変えないなら、型の選択がさらに重い

四つの対応はすべて Conversion: None とされる。GIF を JPEG に再符号化する規則ではなく、X.400 と MIME の型を対応させ、画像オクテットをそのまま渡す設計だ。したがって、image/jpeg と書くだけで GIF のバイトが JPEG になることはない。逆に、OID に GIF とあっても入力バイトが本当に GIF かは別の検査が必要になる。

RFC 2046 は image の subtype が具体的な画像形式を名付けると説明する。現在の IANA Media Types も image/gif と image/jpeg を別々に登録している。関連する RFC 2157 の表も mime-gif-body を image/gif、mime-jpeg-body を image/jpeg に対応させる。この整合性は解釈を助けるが、RFC 2158 の文字列を自動修正はしない。

自明に見える訂正にも公式記録が要る

見出し、本文部名、OID の葉、隣接する三項目を合わせれば、第3.4節の MIME 行は image/gif であるはずだという推論が最も自然だ。初期の MIXER images draft も Extended Body Part の GIF を image/gif としている。ただし、その版には FTAM EMA の項目自体がないため、問題の行の訂正文ではない。

そして RFC Editor の RFC 2158 errata 検索は現在、一件も該当しないと返す。「おそらくコピー時の誤り」と分析することはできるが、「公式に訂正済み」とは書けない。実装者が MIME 行を採用したのか、OID と見出しを採用したのか、別文書や私的パッチを参照したのかも、仕様書だけでは分からない。

動作を語るには動作の証拠が必要だ

特定のゲートウェイを評価するには、入力バイトと型、選択された X.400 本文部、完全な OID、マッピング表の版、設定、出力バイトと型、デコーダーの選択結果を同時に保存する必要がある。ハッシュ一致は観測区間でバイトが変わらなかったことを示すだけで、そのバイトとラベルの一致までは証明しない。

Lu Heng の Running-Code Primacy は、公開規則と実行事実を分ける視点を与える。Minimum Initial Specification は、局所的な修正判断を普遍的事実に膨らませない。Reality Layers は、文書、実装、観測がそれぞれ自分の証拠を持つべき理由を示す。

RFC 2158 の一行は、ラベルが無価値だとは言っていない。ラベルは重要だからこそ、他の識別子と衝突した時に照合が要る。形式同一性は、印刷された単語ではなく、名前、OID、バイト、実装、結果を結んだ主張である。

出典