[1] message/global は、国際化されたメッセージの媒体型として RFC 5335 で定義されています。

[7] RFC 6532 - Internationalized Email Headers (2015-10-16 11:38:31 +09:00 版) https://tools.ietf.org/html/rfc6532
[6] RFC 5335 - Internationalized Email Headers (2015-10-16 12:24:22 +09:00 版) https://tools.ietf.org/html/rfc5335

[2] RFC 5335 4.6 は、メッセージが message/global メッセージmessageである条件として、

UTF-8 頭値を含んでいること、または
本体部分の頭欄が UTF-8 値を含むこと

を挙げています。これだけを読むと従来の ASCII だけのメッセージは該当しないように思えますが、わかりにくいことに、3章で、 RFC 5335 で UTF-8 を認めるように拡張された頭部で使われている ASCII 文字は UTF-8 文字とみなす、と定義されています (そもそも ASCII は UTF-8 の部分集合なので)。なので、 RFC 2822 メッセージは message/global でもあります。

message/rfc822 の定義は壊れた (RFC 822 不適合の) メッセージを message/rfc822 と札付けすることを認めています。 RFC 5335 はそれについて明確には述べていませんが、それを禁じる or 禁じていると解釈しなければ矛盾するような記述はありません。

文脈から明らかなのかもしれませんが、「メッセージ」という語は定義されていません。

(名無しさん)

[3] この媒体型に対しては任意の内容転送符号化が認められていますが、可能な場合は 8bit や binary とすることが推奨 (小文字の recommend) されています。更に、7ビット専用の輸送路を通す場合を除き、 8bit や binary を使わなければならない (RFC 2119 の MUST) とされています。

RFC 5335 4.6

(名無しさん)

[4] message/global で RFC 2047 encoded-word が使えるのかどうかは明確ではありません。 (名無しさん)

[5] RFC 5335 は RFC 2822 の生成規則の一部を更新しているので、 RFC 2822 を参照している他の仕様 (追加の頭欄を定義するものなど) も更新されるものと思われます (明記されていませんが)。 RFC 2822 以前に出版され、 RFC 2822 を参照していない仕様に関してはどう解釈するべきなのかは定かではありません。

ちなみに、 MIME 本体で定義されている頭欄は、 RFC 5335 で定義が更新されている Content-Description 以外は影響しないようです。 Content-Type の引数で使われている quoted-string も ASCII だけのまま、変更ありません (utf8-quoted-string には変わっていません)。

(名無しさん)