要約

  • RFC 3458 の Message-Context は、メッセージ全体との想定される操作を示す任意フィールドであり、存在する MIME パートを確定する宣言ではなかった。
  • 誤り、未知、古くなった文脈はローカルな扱いを助け得るが、転送を失敗させたり、フィールドがない場合より表示を悪くしたりしてはならなかった。

メディア型だけでは利用場面を説明できなかった

2003 年には、一つの受信箱が通常の電子メール、ページャー通知、ファクス、録音音声、複合マルチメディアを集め得た。同じテキストでも、手紙、SMS、通話の書き起こしでは人が期待する操作が違う。アイコンやビューアを決めるだけのために大きな本文をすべて調べるのも効率的ではない。

RFC 3458 は最上位に一度だけ置けるフィールドを定義した。初期値は voice-message、fax-message、pager-message、multimedia-message、text-message、none で、大文字小文字を区別せず、欠如は none と同じだった。原文テキスト、RFC Editor 記録、Datatracker、履歴、参照文献、後続の引用、正誤情報が検証可能な規格記録を構成する。

受信側は文脈を用いてビューアやアイコンを選び、一覧を分類・並べ替え、帯域の限られた接続で表示を絞り、返信方法を提案できた。しかしその便利さは、音声、ファクス画像、実行可能物が本文に実在する証明にはならない。

ゲートウェイは由来を残して媒体を変え得た

規格の鮮明な例は、音声メッセージがゲートウェイを通る場面である。ゲートウェイは録音を除き、書き起こしだけを残せる。由来としては音声メッセージでも、受信端末には再生すべき音がない。逆に音声という文脈とファクス本文だけが届いた場合も、クライアントは手元のファクスを表示しなければならない。

RFC 2822 はメッセージ構文を、RFC 2183 は本文パートの disposition を扱った。RFC 2387 と RFC 2557 は複合構造を、RFC 2423 は VPIM の文脈を扱う。Message-Context はこれらを上書きしない。

したがって、不正または誤った分類を理由に転送を拒否したり、表示を放棄したりしてはならなかった。受信側は少なくともフィールドがない場合と同程度に意味のある形で内容を示す必要がある。単純な保存を超える転送時の意味は範囲外とされたため、古い値は観測すべき不一致であって、強制すべき真実ではない。

ヒントは信頼境界を越えられない

セキュリティ節は、アプリケーションらしい文脈が付いたというだけでプログラムを実行してはならないと警告した。悪意ある送信者は資源を消費させ、誤配送を誘い、注意を不当に得られる。フィールドは送信者も本文も認証せず、行為を認可せず、配達、緊急性、人が読んだ事実も証明しない。

RFC 3459 は MIME パートの critical-content を別に定めた。RFC 3938 は後に登録方針を改め、RFC 3864 はヘッダー登録の一般枠組みを与えた。IANA レジストリは割当てを証明するが、特定クライアントの挙動は証明しない。

後年の Heng Lu の現実の層という視点は、宣言された文脈と受信した本文を別の事実として扱う助けになる。動くコードの優先は、実際の MIME 木、変換、代替表示を見るよう促す。最小初期仕様は、小さな任意フィールドが MIME や安全政策を取り込まず協調できる理由を説明する。これらは後から用いる編集上のレンズであり、RFC 著者の内心を示す証拠ではない。

RFC 3458 は、文脈を命令へ昇格させなかったからこそ有用だった。ヘッダーは受信側を準備できるが、読めるものを最終的に決めるのは残った本文である。

出典