要約

  • RFC 1523 の text/enriched は意図的に機能を絞り、ASCII 系の生データを非 MIME リーダーでも耐えられる程度にし、最小実装なら命令を除いて可読な本文を得られるようにした。
  • 未知の効果、表示されないパラメータ、受信側固有の組版、別の multipart/alternative は消え得た。可読な結果は統制された縮退であり、見た目や意味の完全な同一性ではない。

未知を拒まず、効力だけを落とす

1993年9月に Informational として刊行された RFC 1523 は、RFC 1341 の text/richtext を改め、text/enriched を定めた。ワープロの能力をすべてメールへ持ち込むのではなく、通常の文書ソフトが扱えそうな範囲へ表現を限定した。送れるものは減るが、正しく表示される確率は上がるという判断だった。

特に重要なのが未知の書式命令である。受信側が名前を知らなければ、その命令は no-op として扱う。囲まれた文章は読むことができ、指定された効果だけが落ちる。私的拡張には X- を使えたが、正式な拡張には新しいインターネット文書が必要だった。

この設計なら、古いリーダーは未来の語彙を含むメール全体を拒否しなくてよい。しかし、成功は限定的である。新しい警告表示や意味の階層が普通の文章へ変わっても、配送も解析も「成功」と見える。

小さな文法を作成側が守る

命令名は大文字小文字を区別しない ASCII で、山括弧に入り、60文字以内だった。文字としての < は << と書く。多くの環境は対応する閉じ命令を持ち、均衡し、正しく入れ子にならなければならない。

RFC は作成ソフトの負担が増すことを認めている。その代わり表示側はスタックを使える。開始時に状態を積み、終了時に前の状態へ戻る。壊れた入れ子へ寛容に対処する推奨はあっても、交差した構造に一つの正解を与えたわけではない。

CRLF にも縮退の意味があった。一つなら空白になり、N個連続なら N−1 個の可視改行になる。中継経路の物理的な折り返しを段落と誤解せず、空行は保てる。ただし、受信バイト、再構成した論理行、画面の段落を一つの記録で代用することはできない。

見えないパラメータは本文と一緒には残らない

<param> 環境は別の命令に値を渡した。解釈器はそれを利用しても無視してもよいが、読者へ表示してはならない。最小の変換は書式トークンだけでなくパラメータ内容も削除する。文章が自然に読めても、拡張に必要な値は跡形なく失われ得る。

さらに nofill は通常の行詰めと CRLF 処理を止め、verbatim は内部命令の解釈や行揃えまで閉じ命令まで止める。したがって最小リーダーも、単純な文字列置換では足りない。どの状態にいるかを認識する必要がある。

仕様が示した最低適合は、字面の区切りと必要な環境を認識し、命令とパラメータを取り除き、改行規則を適用するものだった。得られるのは読める平文であって、視覚的な複製ではない。

表示は受信側が完成させた

フォント、行幅、字下げ量、行揃え、複数効果の組み合わせはローカル能力に左右された。同時に実現できなければ、最も内側の認識済み命令を優先してよい。二つの準拠リーダーが異なる紙面を作る余地は最初からあった。

より豊かな内容には multipart/alternative が使われる。広く読める text/enriched と ODA のような表現を並べ、能力のある側は後者を、別の側は前者を選ぶ。双方が同じメッセージを受信しても、実際に読んだ表現は異なる。

RFC 1523 は当時、この仕組みにセキュリティ問題はないと記した。これは文書自身の歴史的評価であり、後の拡張、実装、MIME ハンドラー、現在のアプリケーションすべての安全証明ではない。RFC 1563 が RFC 1523 を廃止し、その後 RFC 1896 が RFC 1563 を廃止したが、文書の更新は旧ソフトの一斉消滅を示さない。

採用した資料には、固有名のあるリーダー、配備、実際のメッセージは示されず、普及率、利用者の反応、不正な入力を与えたときの観測結果もない。確認できるのは書式の規則と文書の系譜であり、特定の導入環境の挙動ではない。

残すべき証拠は、元のバイトと文字集合、物理改行、解析スタック、既知・未知命令の判断、非表示パラメータ、選んだ代替部、ローカル描画、人が受け取った意味である。no-op は未来との接続を助けたが、失われた効力まで保存したわけではない。

情報源