Network Working Group Y. Abel, Ed.
Request for Comments: 5335 TWNIC
Updates: 2045, 2822 September 2008
Category: Experimental
Internationalized Email Headers
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements.
電子メールの完全な国際化は、非ASCIIのコンテンツを送信するために、特定のヘッダフィールドで選択した情報を符号化する、とエンベロープアドレスに非ASCII文字を使用するだけでなく、能力を必要とします。また、これらのアドレスとメールヘッダフィールドにそれらに基づいて情報を表現することができることが必要です。この文書は、インターネット電子メールのヘッダフィールドの塩基形態として、というよりもASCII、UTF-8でエンコードされたUnicodeの使用を可能にするインターネットメールの実験的変異体を特定します。このフォームは、関連仕様書で指定されるように、SMTP拡張によって承認する場合にのみ送信に許可されます。要件に適合するRFC 2045のこの仕様のアップデートセクション6.4。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3
2. Background and History . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5
4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5
4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 6
4.3. Syntax Extensions to RFC 2822 . . . . . . . . . . . . . . 6
4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8
4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Full internationalization of electronic mail requires several capabilities:
電子メールの完全な国際化には、いくつかの機能が必要です。
o The capability to transmit non-ASCII content, provided for as part of the basic MIME specification [RFC2045], [RFC2046].
O機能は、基本的なMIME仕様[RFC2045]、[RFC2046]の一部としてのために設けられた非ASCIIコンテンツを送信します。
o The capability to use international characters in envelope addresses, discussed in [RFC4952] and specified in [RFC5336].
[RFC4952]で説明し、エンベロープアドレスで国際的な文字を使用する機能Oと[RFC5336]で指定されました。
o The capability to express those addresses, and information related to them and based on them, in mail header fields, defined in this document.
これらのアドレスを発現し、情報それらに関連し、それらに基づいて、本文書で定義されたメールヘッダフィールドにする能力O。
This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the base form for Internet email header fields. This form is permitted in transmission, if authorized by the SMTP extension specified in [RFC5336] or by other transport mechanisms capable of processing it.
この文書は、インターネット電子メールのヘッダフィールドの塩基形態として、インターネットUTF-8 [RFC3629]にエンコードされたUnicodeの使用を可能にするメールではなく、ASCIIの実験的変異体を特定します。 [RFC5336]で指定されたSMTP拡張によって、またはそれを処理することができる他の輸送メカニズムによって承認する場合、この形態は、送信に許可されます。
This document updates Section 6.4 of RFC 2045. It removes the blanket ban on applying a content-transfer-encoding to all subtypes of message/, and instead specifies that a composite subtype MAY specify whether or not a content-transfer-encoding can be used for that subtype, with "cannot be used" as the default.
RFC 2045のこのドキュメントの更新6.4節それは、メッセージ/のすべてのサブタイプへのコンテンツ転送エンコードを適用する上ブランケット禁止を削除し、代わりに、複合サブタイプは、コンテンツ転送エンコードを使用できるかどうかを指定することを指定デフォルトとして「使用することはできない」と、そのサブタイプのため。
This document also updates [RFC2822] and MIME ([RFC2045]), and the fact that an Experimental specification updates a Standards-Track specification means that people who participate in the experiment have to consider those standards updated.
また、このドキュメントでは、[RFC2822]を更新し、MIME（[RFC2045]）、および実験的仕様が標準トラック仕様を更新しているという事実は、実験に参加し、人々が更新され、これらの基準を考慮しなければならないことを意味します。
Allowing use of a content-transfer-encoding on subtypes of messages is not limited to transmissions that are authorized by the SMTP extension specified in [RFC5336]. Message/global permits use of a content-transfer-encoding.
メッセージのサブタイプのコンテンツ転送エンコードの使用を可能にするには、[RFC5336]で指定されたSMTP拡張によって許可された送信に限定されるものではありません。メッセージ/グローバル許可は、コンテンツ転送エンコードを使用します。
Mailbox names often represent the names of human users. Many of these users throughout the world have names that are not normally expressed with just the ASCII repertoire of characters, and would like to use more or less their real names in their mailbox names.
メールボックス名は、多くの場合、人間のユーザの名前を表します。世界中のこれらのユーザーの多くは、通常の文字だけのASCIIレパートリーで表現されていない名前を持ち、そのメールボックス名に多かれ少なかれ彼らの本当の名前を使用したいと思います。
These users are also likely to use non-ASCII text in their common names and subjects of email messages, both received and sent. This protocol specifies UTF-8 as the encoding to represent email header field bodies.
これらのユーザーはまた、両方が受信および送信され、彼らの共通の名前と電子メールメッセージの対象に非ASCII文字を使用する可能性があります。このプロトコルは、電子メールのヘッダフィールド体を表すためにエンコーディングとしてUTF-8を指定します。
The traditional format of email messages [RFC2822] allows only ASCII characters in the header fields of messages. This prevents users from having email addresses that contain non-ASCII characters. It further forces non-ASCII text in common names, comments, and in free text (such as in the Subject: field) to be encoded (as required by MIME format [RFC2047]). This specification describes a change to the email message format that is related to the SMTP message transport change described in the associated document [RFC4952] and [RFC5336], and that allows non-ASCII characters in most email header fields. These changes affect SMTP clients, SMTP servers, mail user agents (MUAs), list expanders, gateways to other media, and all other processes that parse or handle email messages.
電子メールメッセージ[RFC2822]の伝統的な形式は、メッセージのヘッダフィールドにASCII文字のみを許可します。これは、非ASCII文字を含む電子メールアドレスを持っていることからユーザーを防ぐことができます。それはさらに力非ASCII共通名内のテキスト、コメント、および（な件名のように：フィールド）フリーテキストでエンコードされる（MIME形式[RFC2047]で必要とされます）。この仕様は、関連ドキュメント[RFC4952]及び[RFC5336]に記載のSMTPメッセージトランスポートの変化に関連する電子メールメッセージフォーマットの変更を記述し、それは、ほとんどの電子メールヘッダフィールド内の非ASCII文字を可能にします。これらの変更は、SMTPクライアント、SMTPサーバー、メールユーザエージェント（MUA）、リストのパンダ、他のメディアへのゲートウェイ、および解析または電子メールメッセージを処理する他のすべてのプロセスに影響を与えます。
As specified in [RFC5336], an SMTP protocol extension "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 header fields to systems that cannot handle such messages.
[RFC5336]で指定されるように、SMTPプロトコル拡張「UTF8SMTP」は、メッセージを処理できないシステムにUTF-8のヘッダーフィールドを持つメッセージの送信を防止するために使用されます。
Use of this SMTP extension helps prevent the introduction of such messages into message stores that might misinterpret, improperly display, or mangle such messages. It should be noted that using an ESMTP extension does not prevent transferring email messages with UTF-8 header fields to other systems that use the email format for messages and that may not be upgraded, such as unextended POP and IMAP servers. Changes to these protocols to handle UTF-8 header fields are addressed in [EAI-POP] and [IMAP-UTF8] .
このSMTP拡張の使用が不適切に表示する、またはそのようなメッセージをマングル、誤解かもしれないメッセージストアにこのようなメッセージの導入を防ぐことができます。 ESMTP拡張機能を使用すると、このような未延伸POPやIMAPサーバなどのメッセージのためのメール形式を使用し、それがアップグレードされなくてもよい他のシステムへのUTF-8のヘッダーフィールドと電子メールメッセージを転送妨げないことに留意すべきです。 UTF8ヘッダフィールドを処理するために、これらのプロトコルへの変更は、[EAI-POP]でアドレス指定して[IMAP-UTF8]れます。
The objective for this protocol is to allow UTF-8 in email header fields. Issues such as how to handle messages containing UTF-8 header fields that have to be delivered to systems that have not been upgraded to support this capability are discussed in [DOWNGRADE].
このプロトコルの目的は、電子メールのヘッダフィールドにUTF-8を可能にすることです。このような【DOWNGRADE]に記載されているこの機能をサポートするようにアップグレードされていないシステムに配信されなければならないUTF-8ヘッダーフィールドを含むメッセージを処理する方法などの問題。
A plain ASCII string is also a valid UTF-8 string; see [RFC3629]. In this document, ordinary ASCII characters are UTF-8 characters if they are in headers which contain <utf8-xtra-char>s.
プレーンなASCII文字列も有効なUTF-8文字列です。 [RFC3629]を参照してください。彼らは<UTF8-エクストラ-CHAR> Sが含まれているヘッダにある場合は、この文書では、通常のASCII文字は、UTF-8文字です。
Unless otherwise noted, all terms used here are defined in [RFC2821], [RFC2822], [RFC4952], or [RFC5336].
特に断りのない限り、ここで使用されるすべての用語は、[RFC2822]、[RFC4952]、または[RFC5336]、[RFC2821]で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP extension is advertised by the SMTP server or is permitted by other transport mechanisms.
UTF8SMTP拡張がSMTPサーバによって通知されるか、または他の輸送機構によって許可された場合にSMTPクライアントは、UTF-8形式のヘッダフィールドを送ることができます。
This protocol does NOT change the [RFC2822] rules for defining header field names. The bodies of header fields are allowed to contain UTF-8 characters, but the header field names themselves must contain only ASCII characters.
このプロトコルは、ヘッダフィールド名を定義するために[RFC2822]のルールを変更しません。ヘッダフィールドの遺体は、UTF-8文字を含むように許可されていますが、ヘッダーフィールド名自体はASCII文字のみが含まれている必要があります。
To permit UTF-8 characters in field values, the header definition in [RFC2822] must be extended to support the new format. The following ABNF is defined to substitute those definitions in [RFC2822].
フィールド値のUTF-8文字を可能にするために、[RFC2822]のヘッダ定義は、新しい形式をサポートするように拡張されなければなりません。以下のABNFは、[RFC2822]にそれらの定義を置換するために定義されています。
The syntax rules not covered in this section remain as defined in [RFC2822].
このセクションで説明されていない構文規則は[RFC2822]で定義されて残ります。
UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]:
UTF-8文字は[RFC3629]から取られた以下のABNF [RFC5234]を使用して、オクテットで定義することができます。
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-エクストラ-CHAR = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail
UTF8-2 =％XC2-DF UTF8テール
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2(UTF8-tail) / %xED %x80-9F UTF8-tail / %xEE-EF 2(UTF8-tail)
UTF8-3 =％xE0％XA0-BF UTF8テール/％XE1-EC 2（UTF8-テール）/％XED％x80-9F UTF8テール/％XEE-EF 2（UTF8-尾）
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail )
UTF8-4 =％XF0％X90-BF 2（UTF8-テール）/％XF1-F3 3（UTF8-テール）/％XF4％x80-8F 2（UTF8-尾）
UTF8-tail = %x80-BF
UTF8テール=％のX80-BF
These are normatively defined in [RFC3629], but kept in this document for reasons of convenience.
これらは、規範的に[RFC3629]で定義されていますが、利便性の理由から、このドキュメントに保存されています。
See [RFC5198] for a discussion of normalization; the use of normalization form NFC is RECOMMENDED.
正規化の議論のために[RFC5198]を参照。 NFC形式の正規化の使用が推奨されます。
This specification updates Section 6.4 of [RFC2045]. [RFC2045] prohibits applying a content-transfer-encoding to all subtypes of message/. This specification relaxes the rule -- it allows newly defined MIME types to permit content-transfer-encoding, and it allows content-transfer-encoding for message/global (see Section 4.6).
この仕様は、[RFC2045]のセクション6.4を更新します。 [RFC2045] /メッセージのすべてのサブタイプへのコンテンツ転送符号化を適用すること禁止しています。この仕様は、ルールを緩和する - それは、コンテンツ転送符号化を可能にするために新たに定義されたMIMEタイプを可能にし、それは（セクション4.6を参照）、グローバルメッセージ/のコンテンツ転送エンコードができます。
Background: Normally, transfer of message/global will be done in 8-bit-clean channels, and body parts will have "identity" encodings, that is, no decoding is necessary. In the case where a message containing a message/global is downgraded from 8-bit to 7-bit as described in [RFC1652], an encoding may be applied to the message; if the message travels multiple times between a 7-bit environment and an environment implementing UTF8SMTP, multiple levels of encoding may occur. This is expected to be rarely seen in practice, and the potential complexity of other ways of dealing with the issue are thought to be larger than the complexity of allowing nested encodings where necessary.
背景：通常、メッセージの転送/グローバル8ビットクリーンチャネルで行われます、そして本体部分は、「同一性」エンコーディングを持つことになり、つまり、いかなる復号化が必要ではありません。 [RFC1652]に記載されているように/グローバルメッセージを含むメッセージは7ビット、8ビットから格下げされた場合には、符号化は、メッセージに適用されてもよいです。メッセージは7ビット環境とUTF8SMTPを実装環境との間を複数回移動する場合、符号化の複数のレベルが発生する可能性があります。これは、実際にはほとんど見られないことが予想され、問題に対処する他の方法の潜在的な複雑さは、必要に応じて、ネストされたエンコーディングを可能にする複雑さよりも大きくなると考えられています。
The following rules are intended to extend the corresponding rules in [RFC2822] in order to allow UTF-8 characters.
以下の規則は、UTF-8文字を可能にするために、[RFC2822]に対応するルールを拡張することを意図しています。
FWS = <see [RFC2822], folding white space>
FWSは= <空白を折りたたみ、[RFC2822]を参照してください>
CFWS = <see [RFC2822], folding white space>
CFWSは= <空白を折りたたみ、[RFC2822]を参照してください>
ctext =/ UTF8-xtra-char
CTEXT = / UTF8のLS-CHAR
utext =/ UTF8-xtra-char
utext = / UTF8-エクストラカー
comment = "(" *([FWS] utf8-ccontent) [FWS] ")"
komment = "（" *（[FOS] ytfth-skontent）FOS] "）"
word = utf8-atom / utf8-quoted-string
単語= UTF8-原子/ UTF8引用符で囲まれた文字列
This means that all the [RFC2822] constructs that build upon these will permit UTF-8 characters, including comments and quoted strings. We do not change the syntax of <atext> in order to allow UTF8 characters in <addr-spec>. This would also allow UTF-8 characters in <message-id>, which is not allowed due to the limitation described in Section 4.5. Instead, <utf8-atext> is added to meet this requirement.
これは、これらの上に構築、すべての[RFC2822]構築物は、コメントおよび引用符で囲まれた文字列を含むUTF-8文字を許可することを意味します。私たちは、<addrのスペック>にUTF8文字を可能にするために、<atext>の構文を変更しないでください。これはまた、セクション4.5に記載の制限に許可されていない<メッセージID>でUTF-8の文字を、可能にするであろう。代わりに、<UTF8-atext>は、この要件を満たすために追加されます。
utf8-text = %d1-9 / ; all UTF-8 characters except %d11-12 / ; US-ASCII NUL, CR, and LF %d14-127 / UTF8-xtra-char
UTF8テキスト=％d1-9 /。 ％d11-12 /除くすべてのUTF-8文字。 US-ASCII NUL、CR、およびLF％d14-127 / UTF8-エクストラ-CHAR
utf8-quoted-pair = ("\" utf8-text) / obs-qp
UTF8引用符で囲まれたペア=（ "\" UTF8テキスト）/ OBS-QP
utf8-qcontent = utf8-qtext / utf8-quoted-pair
UTF8-qcontent = UTF8-qtext / UTF8-引用されたペア
utf8-quoted-string = [CFWS] DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE [CFWS]
UTF8引用ストリング= [CFWS] DQUOTE *（[FWS] UTF8-qcontent）FWS] DQUOTE [CFWS]
utf8-ccontent = ctext / utf8-quoted-pair / comment
UTF8-CCONTENT = CTEXT / UTF8引用符で囲まれたペア/コメント
utf8-qtext = qtext / UTF8-xtra-char
UTF8-qtext = qtext / UTF8-エクストラ-CHAR
utf8-atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms. "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / UTF8-xtra-char
UTF8-atext = ALPHA / DIGIT / "！" / "＃" /; 「$」/「％」/以外の任意の文字。コントロール、SP、およびスペシャル。 "＆" / "'" /;原子のために使用されます。 "*" / "+" / " - " / "/" / "=" / "？" / "^" / "_" / "`"/ "{"/ "|" / "}" / "〜" / UTF8-エクストラ-CHAR
utf8-atom = [CFWS] 1*utf8-atext [CFWS]
UTF8-原子= [CFWS] 1 * UTF8-atext [CFWS]
utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS]
UTF8ドット原子= [CFWS] UTF8ドット原子テキスト[CFWS]
utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext)
UTF8ドット原子テキスト= 1 * UTF8-atextの*（ "" 1 * UTF8-atext）
qcontent = utf8-qcontent
コンテンツ= UTF-8コンテンツ
To allow the use of UTF-8 in a Content-Description header field [RFC2045], the following syntax is used:
コンテンツ説明ヘッダフィールド[RFC2045]でUTF-8の使用を可能にするために、以下の構文が使用されます。
description = "Content-Description:" unstructured CRLF
説明=の "Content-説明：" 非構造化CRLF
The <utext> syntax is extended above to allow UTF-8 in all <unstructured> header fields.
<のutext>構文は、すべての<非構造化>ヘッダフィールドにUTF-8を可能にするために、上記拡張されます。
Note, however, this does not remove any constraint on the character set of protocol elements; for instance, all the allowed values for timezone in the Date: headers are still expressed in ASCII. And also, none of this revised syntax changes what is allowed in a <msg-id>, which will still remain in pure ASCII.
しかし、これはプロトコル要素の文字セット上の制約を削除しません、注意してください。例えば、日中の時間帯が許可されているすべての値：ヘッダはまだASCIIで表現されています。そしてまた、この改訂版構文のどれもまだ純粋なASCIIのままになります。<MSG-ID>、で許されているもの変化しません。
Internationalized email addresses are represented in UTF-8. Thus, all header fields containing <mailbox>es are updated to permit UTF-8 as well as an additional, optional all-ASCII alternate address. Note that Message Submission Servers ("MSAs") and Message Transfer Agents (MTAs) may downgrade internationalized messages as needed. The procedure for doing so is described in [DOWNGRADE].
国際化電子メールアドレスは、UTF-8で表現されています。したがって、<メールボックス> ESを含むすべてのヘッダフィールドは、UTF-8、ならびに追加のオプション全ASCII代替アドレスを可能にするように更新されます。必要に応じて提出サーバー（「MSAに」）とメッセージ転送エージェント（MTA）は国際化されたメッセージをダウングレードすることがあり、そのメッセージに注意してください。そうするための手順は、[ダウングレード]に記載されています。
mailbox = name-addr / addr-spec / utf8-addr-spec
メールボックス=名前-addrに/ addrのスペック/ UTF8-addrにスペック
angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / obs-angle-addr
角度-ADDR = / [CFWS] "<" UTF8-ADDR-スペック[ALT-アドレス] ">" [CFWS] / OBS角-ADDR
utf8-addr-spec = utf8-local-part "@" utf8-domain
UTF8-addrに-specは= UTF8-ローカル部分UTF8-ドメイン "@"
utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part
UTF8-ローカル部分= UTF8ドット原子/ UTF8引用符で囲まれた文字列/ OBS-ローカル部分
utf8-domain = utf8-dot-atom / domain-literal / obs-domain
UTF8-ドメイン= UTF8ドット原子/ドメインリテラル/ OBS-ドメイン
alt-address = FWS "<" addr-spec ">"
ALT-アドレス= FWS "<" のaddrスペック ">"
Below are a few examples of possible <mailbox> representations.
以下は、可能な<メールボックス>の表現の例をいくつか示します。
"DISPLAY_NAME" <ASCII@ASCII> ; traditional mailbox format
"DISPLAY_NAME" <ASCII @ ASCII>。伝統的なメールボックス形式
"DISPLAY_NAME" <non-ASCII@non-ASCII> ; UTF8SMTP but no ALT-ADDRESS parameter provided, ; message will bounce if UTF8SMTP extension is not supported
"DISPLAY_NAME" <非ASCII @非ASCII>; UTF8SMTPが、提供なしALT-ADDRESSパラメータ; UTF8SMTP拡張機能がサポートされていない場合にメッセージが返送されます
<non-ASCII@non-ASCII> ; without DISPLAY_NAME and quoted string ; UTF8SMTP but no ALT-ADDRESS parameter provided, ; message will bounce if UTF8SMTP extension is not supported
<非ASCII非ASCII @>。 DISPLAY_NAMEと引用符で囲まれた文字列なし。 UTF8SMTPが、提供なしALT-ADDRESSパラメータ; UTF8SMTP拡張機能がサポートされていない場合にメッセージが返送されます
"DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>> ; UTF8SMTP with ALT-ADDRESS parameter provided, ; ALT-ADDRESS can be used if downgrade is necessary
"DISPLAY_NAME" 非ASCII <ASCII @ ASCII >> @ <非ASCII; ALT-addressパラメータとUTF8SMTP、提供。ダウングレードが必要な場合はALT-ADDRESSを使用することができます
"For" fields containing internationalized addresses are allowed, by use of the new uFor syntax. UTF-8 information may be needed in Received fields. Such information is therefore allowed to preserve the integrity of those fields. The uFor syntax retains the original UTF-8 email address between email address internationalization (EAI)- aware MTAs. Note that, should downgrading be required, the uFor parameter is dropped per the procedure specified in [DOWNGRADE].
「は」国際化アドレスを含むフィールドは、新しいuFor構文を使用することにより、許可されています。 UTF-8の情報が受信分野で必要とされます。このような情報は、したがって、これらのフィールドの整合性を維持するために許可されています。意識のMTA - uFor構文は、メールアドレスの国際化（EAI）との間に、元のUTF-8のメールアドレスを保持します。 、ダウングレード要求されるべきであることに注意してください、uForパラメータは[DOWNGRADE]で指定された手順に従って廃棄されます。
The "Return-Path" header provides the email return address in the mail delivery. Thus, the header is augmented to carry UTF-8 addresses (see the revised syntax of <angle-addr> in Section 4.4 of this document). This will not break the rule of trace field integrity, because the header is added at the last MTA and described in [RFC2821].
「リターンパスは、」ヘッダは、メール配信でメールのリターンアドレスを提供します。したがって、ヘッダは、UTF-8（このドキュメントのセクション4.4で<角度-ADDR>の改訂版構文を参照）アドレスを運ぶために拡張されます。ヘッダが最後のMTAに追加され、[RFC2821]に記述されているので、これは、トレースフィールドの整合性のルールを破ることはありません。
The <item-value> on "Received:" syntax is augmented to allow UTF-8 email address in the "For" field. <angle-addr> is augmented to include UTF-8 email address. In order to allow UTF-8 email addresses in an <addr-spec>, <utf8-addr-spec> is added to <item-value>.
構文は、フィールド「のために」でUTF-8のメールアドレスを許可するように拡張されます：「受信」の<項目値>。 <角度-addrに> UTF-8のメールアドレスが含まれるように拡張されます。 <ADDR仕様>でUTF-8の電子メールアドレスを可能にするために、<UTF8-ADDR-スペックが> <項目値>に加算されます。
item-value =/ utf8-addr-spec
項目値= / UTF8-ADDR-スペック
Internationalized messages must only be transmitted as authorized by [RFC5336] or within a non-SMTP environment which supports these messages. A message is a "message/global message", if
[RFC5336]によって、あるいは、これらのメッセージをサポートしている非SMTP環境で認可として国際化されたメッセージのみを送信する必要があります。メッセージがあれば、「メッセージ/グローバルメッセージ」であります
o it contains UTF-8 header values as specified in this document, or
Oそれは、この文書で指定されているUTF-8ヘッダ値を含む、または
o it contains UTF-8 values in the headers fields of body parts.
Oそれは身体のパーツのヘッダフィールドにUTF-8の値が含まれています。
The type message/global is similar to message/rfc822, except that it contains a message that can contain UTF-8 characters in the headers of the message or body parts. If this type is sent to a 7-bit-only system, it has to be encoded in MIME [RFC2045]. (Note that a system compliant with MIME that doesn't recognize message/global would treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].)
/グローバルタイプのメッセージは、メッセージ又は身体部分のヘッダにUTF-8文字を含むことができるメッセージを含むことを除いて、メッセージ/ RFC822に類似しています。このタイプは、7ビットのみのシステムに送信されている場合は、MIME [RFC2045]で符号化されなければなりません。 （メッセージを認識しないMIMEに準拠したシステムは、/「アプリケーション/オクテットストリーム」として扱うことになるグローバル[RFC2046]のセクション5.2.4に記載されるようにすることに注意してください。）
Alternatively, SMTP servers and other systems which transfer a message/global body part MAY choose to down-convert it to a message/ rfc822 body part using the rules described in [DOWNGRADE].
代替的に、SMTPサーバ及びメッセージ/グローバル身体部分を転送する他のシステムがダウンコンバート[DOWNGRADE]に記載のルールを使用してメッセージ/ RFC822ボディ部分にそれをすることを選択することができます。
Type name: message
型名：メッセージ
Subtype name: global
サブタイプ名：グローバル
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted.
エンコードの考慮事項：任意のContent-Transfer-Encodingをが許可されています。許可されている場合、8ビットまたはバイナリコンテンツ転送符号化が推奨されます。
Security considerations: See Section 5.
セキュリティの考慮事項：第5節を参照してください。
Interoperability considerations: The media type provides functionality similar to the message/rfc822 content type for email messages with international email headers. When there is a need to embed or return such content in another message, there is generally an option to use this media type and leave the content unchanged or down-convert the content to message/rfc822. Both of these choices will interoperate with the installed base, but with different properties. Systems unaware of international headers will typically treat a message/global body part as an unknown attachment, while they will understand the structure of a message/ rfc822. However, systems that understand message/global will provide functionality superior to the result of a down-conversion to message/rfc822. The most interoperable choice depends on the deployed software.
相互運用性に関する注意事項：メディアタイプは、国際電子メールのヘッダを持つ電子メールメッセージのメッセージ/ RFC822のコンテンツタイプに似た機能を提供します。別のメッセージでこのようなコンテンツを埋め込むか、返却する必要がある場合は、このメディアタイプを使用すると、そのまま又はダウンコンバートコンテンツはメッセージ/ RFC822にコンテンツを残すためのオプションは、一般的にあります。これらの選択肢の両方がインストールベースと相互運用が、異なる性質を持つだろう。彼らはメッセージ/ RFC822の構造を理解しながら、国際的なヘッダを知らないシステムでは、通常、未知の添付ファイルとしてメッセージ/グローバル身体の部分を扱います。ただし、メッセージ/グローバルを理解するシステムでは、メッセージ/ RFC822へのダウンコンバートの結果に優れた機能を提供します。ほとんどの相互運用可能な選択が展開されたソフトウェアに依存します。
Published specification: RFC 5335
公開された仕様：RFC 5335
Applications that use this media type: SMTP servers and email clients that support multipart/report generation or parsing. Email clients which forward messages with international headers as attachments.
マルチパート/レポート生成や解析をサポートするSMTPサーバおよび電子メールクライアント：このメディアタイプを使用するアプリケーション。添付ファイルとして国際ヘッダを持つメッセージを転送する電子メールクライアント。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー（S）：なし
File extension(s): The extension ".u8msg" is suggested.
ファイルの拡張子（S）：拡張子「.u8msg」が示唆されました。
Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message" is suggested. This conforms to "public.message" and "public.composite-content", but does not necessarily conform to "public.utf8-plain-text".
Macintoshファイルタイプコード（S）：均一なタイプ識別子（UTI）「public.utf8-電子メールメッセージ」のが示唆されました。これは、「public.message」と「public.compositeコンテンツ」に準拠して、必ずしも「public.utf8-プレーンテキスト」に準拠していません。
Person & email address to contact for further information: See the Author's Address section of this document.
人とEメールアドレスは、詳細のために連絡する：この文書の著者のアドレスのセクションを参照してください。
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This is a structured media type which embeds other MIME media types. The 8-bit or binary content-transfer-encoding MUST be used unless this media type is sent over a 7-bit-only transport.
使用に関する制限事項：これは、他のMIMEメディアタイプを埋め込む構造化されたメディアタイプです。このメディアタイプは、7ビットのみトランスポートを介して送信されていない限り、8ビットまたはバイナリコンテンツ転送符号化が使用されなければなりません。
Author: See the Author's Address section of this document.
著者：本書の著者のアドレスのセクションを参照してください。
Change controller: IETF Standards Process
変更コントローラ：IETF標準化プロセス
If a user has a non-ASCII mailbox address and an ASCII mailbox address, a digital certificate that identifies that user may have both addresses in the identity. Having multiple email addresses as identities in a single certificate is already supported in PKIX (Public Key Infrastructure for X.509 Certificates) and OpenPGP.
ユーザーは、非ASCIIメールボックスアドレスとASCIIのメールボックスアドレス、ユーザーがIDで両方のアドレスを持っていることを識別するデジタル証明書を持っている場合。単一の証明書で身元など、複数のメールアドレスを持つことは、すでにPKIX（X.509証明書の公開鍵インフラストラクチャ）とのOpenPGPでサポートされています。
Because UTF-8 often requires several octets to encode a single character, internationalized local parts may cause mail addresses to become longer. As specified in [RFC2822], each line of characters MUST be no more 998 octets, excluding the CRLF.
UTF-8は、多くの場合、単一の文字をエンコードするために、いくつかのオクテットを必要とするため、国際地元の部品は、メールアドレスが長くなることがあります。 [RFC2822]で指定されるように、文字の各行はCRLFを除く、これ以上998オクテットてはなりません。
Because internationalized local parts may cause email addresses to be longer, processes that parse, store, or handle email addresses or local parts must take extra care not to overflow buffers, truncate addresses, or exceed storage allotments. Also, they must take care, when comparing, to use the entire lengths of the addresses.
国際地元の部品は、電子メールアドレスは、長い解析プロセス、店舗、または、バッファをオーバーフローしないように細心の注意を取るアドレスを切り捨てる、またはストレージ割り当てを超えていなければならない電子メールアドレスまたはローカル部分を処理するために発生することがありますので。比較するときにも、彼らは、アドレスの全体の長さを使用するように、注意しなければなりません。
In this specification, a user could provide an ASCII alternative address for a non-ASCII address. However, it is possible these two addresses go to different mailboxes, or even different people. This configuration may be based on a user's personal choice or on administration policy. We recognize that if ASCII and non-ASCII email is delivered to two different destinations, based on MTA capability, this may violate the principle of least astonishment, but this is not a "protocol problem".
この仕様では、ユーザーは、非ASCIIアドレスのASCII代替アドレスを提供することができます。しかし、これらの2つのアドレスが異なるメールボックス、あるいは別の人に行くことも可能です。この構成では、ユーザーの個人の選択や管理ポリシーに基づいてもよいです。私たちは、ASCIIと非ASCIIメールがMTAの能力に基づいて、二つの異なる宛先に配信された場合、これは驚き最小の原則に違反する可能性があり、これは、「プロトコルの問題」ではないことを認識しています。
The security impact of UTF-8 headers on email signature systems such as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is discussed in RFC 4952, Section 9. A subsequent document [DOWNGRADE] will cover the impact of downgrading on these systems.
そのようなドメインキーとして電子メール署名システムでUTF-8のヘッダーメール（DKIM）、S / MIMEを、同定し、OpenPGPのは、RFC 4952に説明され、第9のセキュリティへの影響は、後続の文書[ダウングレード]にダウングレードの影響をカバーしますこれらのシステム。
IANA has registered the message/global MIME type using the registration form contained in Section 4.4.
IANAはセクション4.4に含まれる登録フォームを使用してメッセージ/グローバルMIMEタイプを登録しています。
This document incorporates many ideas first described in Internet-Draft form by Paul Hoffman, although many details have changed from that earlier work.
多くの詳細は、その初期の作品から変更されていますが、この文書では、最初のポール・ホフマンによるインターネットドラフトフォームに記載されている多くのアイデアが組み込まれています。
The author especially thanks Jeff Yeh for his efforts and contributions on editing previous versions.
著者彼の努力と、以前のバージョンの編集の貢献のために特に感謝ジェフ・イェー。
Most of the content of this document is provided by John C Klensin. Also, some significant comments and suggestions were received from Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team (Joint Engineering Team) and were incorporated into the document. The editor sincerely thanks them for their contributions.
このドキュメントの内容のほとんどは、ジョン・C Klensinにより提供されます。また、いくつかの重要なコメントや提案は、チャールズ・H・リンジー、カリHurtta、ピート・レズニック、アレクセイ・メルニコフ、クリス・ニューマン、Yangwooコ、芳郎米谷、およびJETチーム（合同エンジニアリングチーム）の他のメンバーから受信し、中に組み込まれました資料。彼らの貢献のためのエディタは心から感謝して。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J.とM. Padlipsky、 "ネットワークインターチェンジのUnicodeフォーマット"、RFC 5198、2008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336]八尾、J.、エド。そしてW.真央、エド。、 "国際化メールアドレスのSMTP拡張"、RFC 5336、2008年9月。
[DOWNGRADE] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
[DOWNGRADE]藤原、K.とY.米谷、「メールアドレスの国際化のためのメカニズムのダウングレード」、進歩、2008年7月に作業。
[EAI-POP] Newman, C. and R. Gellens, "POP3 Support for UTF-8", Work in Progress, July 2008.
[EAI-POP]ニューマン、C.とR. Gellens、 "UTF-8用のPOP3サポート"、進歩、2008年7月に作業。
[IMAP-UTF8] Resnick, P. and C. Newman, "IMAP Support for UTF-8", Work in Progress, April 2008.
[IMAP-UTF8]レズニック、P.とC.ニューマン、 "UTF8のためのIMAPサポート"、進歩、2008年4月の作業。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
Author's Address
著者のアドレス
Abel Yang (editor) TWNIC 4F-2, No. 9, Sec 2, Roosvelt Rd. Taipei, 100 Taiwan
アベルヤン（編集）TWNIC 4F-2、9号、章2、Roosvelt Rdを。台北100台湾
Phone: +886 2 23411313 ext 505 EMail: abelyang@twnic.net.tw
電話：+886 2 23411313 ext 505 Eメール：abelyang@twnic.net.tw
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。