3. メッセージヘッダフィールドの変更
フィールド値で非 ASCII の Unicode 文字を許可するため, [RFC5322] のヘッダ定義が新しい形式をサポートするように拡張される. 以下の各セクションは, RFC 5322 の ABNF に必要な変更を規定する.
以下に言及されていない構文規則は, [RFC5322] で定義されているとおりのままである.
本プロトコルは, ヘッダフィールド名を定義するための RFC 5322 の規則を変更しないことに注意されたい. ヘッダフィールドの本体は Unicode 文字を含むことができるが, ヘッダフィールド名自体は ASCII 文字のみで構成されなければならない.
また, この形式のメッセージを SMTP 経由で転送するには SMTPUTF8 拡張 [RFC6531] を使用する必要があることに注意されたい.
3.1. UTF-8 の構文と正規化
UTF-8 文字は, [RFC3629] から引用した以下の ABNF [RFC5234] を用いてオクテットの観点で定義できる:
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC3629>
UTF8-3 = <Defined in Section 4 of RFC3629>
UTF8-4 = <Defined in Section 4 of RFC3629>
Unicode 正規化の議論については [RFC5198] を参照されたい; 正規化形式 NFC [UNF] を使用すべき (SHOULD) である. 実際, 国際化を適切に行う場合, 最も頻繁に挙げられる目標の 1 つは, 人々が自分の名前を正しく綴れるようにすることである. 多くのメールボックスの local part は個人名を反映しているため, この原則はメールボックスにも当てはまる. NFKC 正規化形式 [UNF] は, まれな状況で一部の名前を正しく綴るために必要な情報を失う可能性があるため, 使用すべきでない (SHOULD NOT).
3.2. RFC 5322 への構文拡張
以下の規則は, UTF-8 内容を許可するために [RFC5322] および [RFC5234] で定義された ABNF 構文を拡張するものである.
VCHAR =/ UTF8-non-ascii
ctext =/ UTF8-non-ascii
atext =/ UTF8-non-ascii
qtext =/ UTF8-non-ascii
text =/ UTF8-non-ascii
; note that this upgrades the body to UTF-8
dtext =/ UTF8-non-ascii
上記の変更は, 以下の構文が UTF-8 を許可するようになったことを意味する:
-
非構造化テキスト (unstructured text). "Subject:" や "Content-description:" などのヘッダフィールドで使用される.
-
atom を使用するあらゆる構文. これにはアドレスや Message-ID の local part が含まれるが, これらに限定されない. これには "Received:" ヘッダフィールドの "for" 節のアドレスも含まれる.
-
引用符付き文字列 (quoted string).
-
ドメイン (domain).
ヘッダフィールド名はこの一覧に含まれないことに注意されたい; これらは依然として ASCII に制限されている.
3.3. Message-ID における 8-bit UTF-8 の使用
Message-ID 生成アルゴリズムの実装者は, 出力を ASCII に制限することを好むかもしれない (MAY). これにはいくつかの利点がある. たとえば, 一部の送信者が国際化アドレスを使用し他の送信者が使用しないメーリングリストのスレッドにおいて "In-reply-to:" および "References:" ヘッダフィールドを構築する場合などである.
3.4. 行長制限への影響
[RFC5322] のセクション 2.1.1 は行を 998 文字に制限し, 行を 78 文字のみに制限することを推奨している. 本仕様は前者の制限を 998 オクテットに変更する. (ASCII ではオクテットと文字は事実上同じであるが, UTF-8 ではそうではないことに注意されたい.) 78 文字の制限は, 行長の問題ではなく表示幅の問題に対処することを意図しているため, オクテットではなく文字の観点で定義されたままである.
3.5. MIME メッセージ型エンコーディング制限の変更
本仕様は [RFC2045] のセクション 6.4 を更新する. [RFC2045] は "message/" の任意のサブタイプに content-transfer-encoding を適用することを禁止している. 本仕様はこの規則を緩和する -- 新しく定義される MIME タイプが content-transfer-encoding を許可できるようにし, また message/global に対して content-transfer-encoding を許可する (セクション 3.7 を参照).
背景: 通常, message/global の転送は 8-bit-clean なチャネルで行われ, ボディパートは "identity" エンコーディング, すなわちデコードが不要なものとなる.
しかし, [RFC6152] に記載されているように message/global を含むメッセージが 8-bit から 7-bit にダウングレードされる場合, そのメッセージにエンコーディングを適用しなければならないことがある. メッセージが 7-bit 環境とこれらの拡張を実装する環境との間を複数回往復すると, 複数レベルのエンコーディングが生じる可能性がある. これは実際にはほとんど見られないと予想されており, この問題に対処する他の方法の潜在的な複雑さは, 必要に応じてネストしたエンコーディングを許可する複雑さよりも大きいと考えられている.
3.6. MIME 符号化語の使用
MIME の符号化語 (encoded-words) 機能 [RFC2047] は非 ASCII テキストを配置する能力を提供するが, それは本拡張で許可される場所の一部のサブセットに限られる. さらに, 符号化語は任意の文字セットの使用を許可するため, はるかに複雑である. したがって, 本拡張を採用するメッセージのヘッダフィールドを生成する際には, 符号化語を使用すべきでない (SHOULD NOT). エージェントは, 別のメッセージからの資料を取り込む際に, 符号化語の使用を UTF-8 の直接使用に変換してもよい (MAY).
符号化語をデコードする際には注意が必要である. 符号化語をその UTF-8 でのデコード結果に置き換えた後の結果が構文的に不正になる可能性があるためである. 符号化語をデコードすることを選択したプロセッサは, 構文的に不正なフィールドを生成してはならない (MUST NOT).
3.7. message/global メディアタイプ
この形式の国際化メッセージは, [RFC6531] によって認可された場合, またはこれらのメッセージをサポートする非 SMTP 環境内でのみ転送しなければならない (MUST). 以下のいずれかに該当するメッセージは "message/global メッセージ" である:
-
本文書で規定される 8-bit UTF-8 ヘッダ値を含むもの, または
-
ボディパートのヘッダフィールドに 8-bit UTF-8 値を含むもの.
message/global パートの内容は, それ以外の点では message/rfc822 パートの内容と同一である.
このタイプのオブジェクトが 7-bit 専用システムに送信される場合, 適切な content-transfer-encoding を適用しなければならない (MUST). (MIME に準拠しているが message/global を認識しないシステムは, [RFC2046] のセクション 5.2.4 に記載されているように, これを "application/octet-stream" として扱うことになっていることに注意されたい.)
登録内容は以下のとおりである:
Type name: message
Subtype name: global
Required parameters: none
Optional parameters: none
Encoding considerations: 任意の content-transfer-encoding が許可される. 許可される場合は 8-bit または binary の content-transfer-encoding が推奨される.
Security considerations: セクション 4 を参照.
Interoperability considerations: このメディアタイプは, 国際化電子メールヘッダを持つ電子メールメッセージに対して, message/rfc822 コンテンツタイプと同様の機能を提供する. そのような内容を別のメッセージに埋め込むか返送する必要がある場合, 一般に, このメディアタイプを使用して内容を変更しないままにするか, 内容を message/rfc822 にダウンコンバートするかの選択肢がある. いずれの選択も既存の実装と相互運用するが, 特性は異なる. 国際化ヘッダを認識しないシステムは通常, message/global ボディパートを未知の添付ファイルとして扱うが, message/rfc822 の構造は理解する. しかし, message/global を理解するシステムは, message/rfc822 へのダウンコンバートの結果より優れた機能を提供する. 最も相互運用性の高い選択は, 配備されているソフトウェアに依存する.
Published specification: RFC 6532
Applications that use this media type: multipart/report の生成または解析をサポートする SMTP サーバおよび電子メールクライアント. 国際化ヘッダを持つメッセージを添付ファイルとして転送する電子メールクライアント.
Additional information:
Magic number(s): none
File extension(s): 拡張子 ".u8msg" が推奨される.
Macintosh file type code(s): 統一型識別子 (UTI) "public.utf8-email-message" が推奨される. これは "public.message" および "public.composite-content" に準拠するが, 必ずしも "public.utf8-plain-text" に準拠するわけではない.
Person & email address to contact for further information: 本文書の「作者のアドレス」セクションを参照.
Intended usage: COMMON
Restrictions on usage: これは他の MIME メディアタイプを埋め込む構造化メディアタイプである. このメディアタイプが 7-bit 専用トランスポートで送信される場合を除き, 8-bit または binary の content-transfer-encoding を使用すべきである (SHOULD).
Author: 本文書の「作者のアドレス」セクションを参照.
Change controller: IETF Standards Process