要約

  • RFC 3676 は DelSp を加え、語の区切りとして元からある空白と、ソフト改行を示すため送信側が挿入した空白を区別した。
  • 既定値は no。ASCII 空白をほとんど使わない、または使わない文字体系で新しい改行方式を採る場合、送信側は DelSp=yes を明示し、受信側が連結時に印だけを削除できるようにする。

行末の空白は、一見すると同じでも意味が二通りある。text/plain; format=flowed では、段落が表示幅を越えて次の物理行に続いていることを示せる。しかしその空白は、もともと二つの語の間にあったのか、それともメールソフトが折り返し用に加えたのか。2004年の RFC 3676 は DelSp でこの違いを明示した。RFC 2646 を置き換え、flowed text を保ちながら、受信側が改行を復元する際の規則を補っている（§§4–4.2）。

従来の方法では、語間に空白がすでにある位置でしか折り返せなかった。送信側はその空白の後ろに CRLF を置き、受信側は物理行をつなぐ際に空白を残す。この方法には DelSp=no を使うよう RFC は推奨する。その空白は文章の一部であり、レイアウトの印として削除する対象ではないからだ。

ASCII 空白をほとんど使わない、または使わない文字体系では、自然な語間の切れ目が常にあるとは限らない。新しい方法は、任意の適切な位置に SP CRLF を挿入できる。行末の空白が続きの印になり、DelSp=yes なら受信側は行を連結するときにその一つを取り除く。そうしなければ、表示のための変換が元の文字列に存在しなかった文字を足すことになる。そのため RFC 3676 はこの方法に DelSp=yes を必須としている。これは受信側に言語を推測させる仕組みではなく、送信側が採用した符号化方法を宣言する仕組みだ（§§4.1–4.2）。

パラメーターがない場合の扱いも決まっている。DelSp が省略されるか値を認識できなければ、受信側は no とみなす。Format=Flowed なしの DelSp は未定義であり、text/plain; format=flowed 以外で使われた場合、受信側は無視すべきとされる。したがって、末尾の空白を合成印だと推測してはいけない。この既定値は従来の読み方を保つ一方、必要なメタデータが失われた後に送信側の意図まで復元するものではない。

印を置く側も重要だ。元からある空白の直前に SP CRLF を差し込むと、その空白が次の行の先頭に回る。flowed text は先頭が空白、>、または From の行に space-stuffing を適用するため、位置選択が追加処理を招く。RFC 3676 は、既存の空白の後ろに SP CRLF を挿入するよう推奨している。語を区切る空白と改行を示す印を、別々の要素として保てる（§§4.2、4.4）。

規定の範囲は狭い。RFC 3676 が定めるのは送信中の text/plain 形式であって、ローカルファイルの保存方法ではない。MIME の content-transfer-encoding も別の層だ。署名・暗号化と再整形の順序にも触れているが、その暗号学的な論点は RFC 2646 の別稿が担うため、ここでは繰り返さない。規範文書だけでは、特定のメールソフトが実際に従ったとは言えない。Lu Heng の Note 65 の視点に沿えば、仕様に書かれた動作と稼働中のコードで観測した動作は別の証拠である。ユーザーに何が表示されたかを論じるには、バージョンを特定した実装と捕捉メッセージが要る。

出典

  • RFC 3676、特に §§4.1–4.2 と付録 A。
  • RFC 2646、先行する flowed text 仕様。
  • RFC 2046、MIME メディアタイプの枠組み。
  • RFC 2045、MIME 本文と転送符号化の文脈。
  • Lu Heng, Note 65、明示した分析視点であり、実装の証拠ではない。