Network Working Group J. Yao, Ed.
Request for Comments: 5336 W. Mao, Ed.
Updates: 2821, 2822, 4952 CNNIC
Category: Experimental September 2008
SMTP Extension for Internationalized Email Addresses
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
抽象
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.
この文書では、国際化電子メールアドレスまたはヘッダー情報を輸送し、電子メールメッセージの配信のためのSMTPの拡張子を指定します。この仕様を実装していないシステムとの通信は、別の文書で指定されています。この文書は、RFC 2821およびRFC 2822で定義されたいくつかの構文とルールを更新し、いくつかの材料の更新RFC 4952を持っています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 9
3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 10
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 12
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 20
A.1. Conventional Message and Internationalized Message . . . . 20
A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 20
A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 20
A.5. Applicability of SMTP Extension to Additional Uses . . . . 21
An internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of clients and servers, while domain names are resolved by name servers looking up those names in their own tables. In addition to this, the Simple Mail Transfer Protocol [RFC2821] provides a negotiation mechanism about service extension with which clients can discover server capabilities and make decisions for further processing. An extended overview of the extension model for internationalized addresses and headers appears in [RFC4952], referred to as "the framework document" or just as "Framework" elsewhere in this specification. This document specifies an SMTP extension to permit internationalized email addresses in envelopes, and UNICODE characters (encoded in UTF-8) [RFC3629] in headers.
国際化電子メールアドレスは二つの部分、ローカル部分とドメイン部分を含んでいます。電子メールアドレスは、プロトコルによって使用されている方法は、ドメイン名が使用されている方法とは異なります。最も重要な違いは、ドメイン名は、自分のテーブルにそれらの名前を検索するネームサーバによって解決されている間、電子メールが、クライアントとサーバのチェーンを介して配信されているということです。これに加えて、簡易メール転送プロトコル[RFC2821]は、クライアントがサーバーの能力を発見し、さらに処理するために意思決定を行うことが可能なサービス拡張に関する交渉メカニズムを提供します。国際アドレスとヘッダの拡張モデルの拡張の概要は、[RFC4952]に表示され、「フレームワーク文書」として、または単に本明細書の他の箇所で「フレームワーク」と呼びます。この文書は、ヘッダー内の（UTF-8でエンコードされた）国際封筒での電子メールアドレス、およびUnicode文字を許可するSMTP拡張[RFC3629]を指定します。
The framework document specifies the requirements for, and describes components of, full internationalization of electronic mail. A thorough understanding of the information in that document and in the base Internet email specifications [RFC2821] [RFC2822] is necessary to understand and implement this specification.
枠組み文書はのための要件を指定し、電子メールの完全な国際化のコンポーネントについて説明します。その文書で、ベースのインターネット電子メールの仕様の情報を完全に理解[RFC2821] [RFC2822]はこの仕様を理解し、実施する必要があります。
This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension [RFC2821] for internationalized email address transport delivery.
この文書は、電子メールの国際化作業の要素、国際化電子メールアドレス輸送配信のためのSMTP拡張[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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The terms "conventional message" and "internationalized message" are defined in an appendix to this specification. The terms "UTF-8 string" or "UTF-8 character" are used informally to refer to Unicode characters encoded in UTF-8 [RFC3629]. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications [RFC2821] [RFC2822]. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "i18mail address", "UTF8SMTP", "message", and "mailing list" are used in this document according to the definitions in the framework document.
用語「従来のメッセージ」および「国際メッセージ」は、本明細書の付録に定義されています。用語「UTF-8文字列」または「UTF-8文字は、」UTF-8 [RFC3629]でエンコードされたUnicode文字を参照するために非公式に使用されています。本明細書において使用される他のすべての専門用語は、フレームワーク文書にまたはベースのインターネット電子メールの仕様[RFC2821] [RFC2822]で定義されています。特に、用語「ASCIIアドレス」、「国際化電子メールアドレス」、「非ASCIIアドレス」、「i18mailアドレス」、「UTF8SMTP」、「メッセージ」、および「メーリングリスト」を定義に従って、このドキュメントで使用されています枠組み文書インチ
This specification defines only those Augmented BNF (ABNF) [RFC5234] syntax rules that are different from those of the base email specifications [RFC2821][RFC2822] and, where the earlier rules are upgraded or extended, gives them new names. When the new rule is a small modification to the older one, it is typically given a name starting with "u". Rules that are undefined here may be found in the base email specifications under the same names.
この仕様は、以前のルールをアップグレードまたは拡張されているベースの電子メールの仕様[RFC2821] [RFC2822]と、のものとは異なるもののみ拡張BNF（ABNF）[RFC5234]構文規則を定義して、彼らに新しい名前を与えます。新しいルールが古いものに小さな変更である場合、それは一般的に「U」で始まる名前を与えられています。ここでは未定義のルールは、同じ名前の下にベースの電子メールの仕様で見ることができます。
This specification describes an optional extension to the email transport mechanism that permits non-ASCII [ASCII] characters in both the envelope and header fields of messages, which are encoded with UTF-8 [RFC3629] characters. The extension is identified with the token "UTF8SMTP". In order to provide information that may be needed in downgrading, an optional alternate ASCII address may be needed if an SMTP client attempts to transfer an internationalized message and encounters a server that does not support this extension.
この仕様は、UTF-8 [RFC3629]の文字で符号化されたメッセージの両方のエンベロープとヘッダフィールドで非ASCII [ASCII]文字を許可するメール搬送機構に任意の拡張子を記述する。拡張子は、トークン「UTF8SMTP」で識別されます。 SMTPクライアントは、国際化されたメッセージを転送しようとすると、この拡張をサポートしていないサーバが発生した場合格下げに必要とされる情報を提供するために、任意選択の代替のASCIIアドレスが必要とされ得ます。
The EAI UTF-8 header specification [RFC5335] provides the details of how and where non-ASCII characters are permitted in the header fields of messages. The context for this specification is described in the framework document.
EAI UTF-8ヘッダー仕様[RFC5335]は、非ASCII文字は、メッセージのヘッダフィールドで許可されている方法と場所の詳細を提供します。本明細書のコンテキストは、フレームワーク文書に記載されています。
The following service extension is defined:
以下のサービス拡張が定義されています。
1. The name of the SMTP service extension is "Email Address Internationalization".
1. SMTPサービス拡張の名前は、「メールアドレスの国際化」です。
2. The EHLO keyword value associated with this extension is "UTF8SMTP".
2.この拡張子に関連付けられているEHLOキーワード値は「UTF8SMTP」です。
3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for that keyword. Clients MUST ignore any parameters; that is, clients MUST behave as if the parameters do not appear. If a server includes UTF8SMTP in its EHLO response, it MUST be fully compliant with this version of this specification.
3.ませパラメータ値は、このEHLOキーワード値のために定義されていません。未来を可能にするためには拡張子（予期せぬが）、EHLO応答は、そのキーワードのいずれかのパラメータを含めることはできません。クライアントは、任意のパラメータを無視しなければなりません。つまり、クライアントは、パラメータが表示されないかのように動作しなければなりません。サーバがEHLO応答でUTF8SMTPが含まれている場合、それは、この仕様書のこのバージョンに完全に準拠しなければなりません。
4. One optional parameter, ALT-ADDRESS, is added to the MAIL and RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII address which can be used as a substitute for the corresponding primary (i18mail) address when downgrading. More discussion of the use of this parameter appears in [RFC4952] and [Downgrade].
4つの任意のパラメータ、ALT-ADDRESSは、SMTPのメール、RCPTコマンドに付加されます。 ALT-ADDRESSは、ダウングレードする場合、対応するプライマリ（i18mail）アドレスの代用として使用することができる全ASCIIアドレスを指定します。このパラメータの使用の詳しい議論は[RFC4952]と[ダウングレード]に表示されます。
5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN commands. The parameter UTF8REPLY has no value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.
5.一つのオプションのパラメータ「UTF8REPLYは」VRFYとEXPNコマンドに追加されます。パラメータUTF8REPLYには値がありません。パラメータは、SMTPクライアントはVRFYとEXPNコマンドからの返信でUTF-8エンコーディングでUnicode文字を受け入れることができることを示します。
7. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC1652].
サポートを提供し、発表しなければならないこの拡張機能を提供7.サーバー、8BITMIME拡張[RFC1652]。
8. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses).
8.逆パスおよびSMTPメールとRCPTコマンドのフォワードパスは、メールボックス名（アドレス）にUTF-8でエンコードされたUnicode文字を許可するように拡張されます。
10. The maximum length of MAIL and RCPT command lines is increased by 460 characters by the possible addition of the ALT-ADDRESS keyword and value.
10. MAILとRCPTコマンドラインの最大長さは、ALT-ADDRESSのキーワードと値の可能な添加によって460文字だけ増加させます。
11. The UTF8SMTP extension is valid on the submission port [RFC4409].
11. UTF8SMTP拡張子はサブミッションポート[使いrfc4409]で有効です。
An SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 2821 specifies that a mailbox can appear. That string MUST be parsed only as specified in RFC 2821, i.e., by separating the mailbox into source route, local part, and domain part, using only the characters colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. Once isolated by this parsing process, the local part MUST be treated as opaque unless the SMTP server is the final delivery Mail Transfer Agent (MTA). Any domain names that are to be looked up in the DNS MUST first be processed into the form specified in "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] by means of the ToASCII() operation unless they are already in that form. Any domain names that are to be compared to local strings SHOULD be checked for validity and then MUST be compared as specified in Section 3.4 of IDNA.
この拡張機能を発表しましたSMTPサーバは、RFC 2821は、メールボックスが表示されることを指定した任意の位置でのUTF-8文字列[RFC3629]を受け入れるように準備しなければなりません。その文字列は、文字だけ結腸（U + 003A）を使用して、ソースルート、ローカル部分とドメイン部分にメールボックスを分離することにより、すなわち、RFC 2821で指定のみとして解析カンマ（U + 002C）、およびAT-なければなりませんそこに指定されるように記号（U + 0040）。 SMTPサーバは最終送出メール転送エージェント（MTA）でない限り、一度この解析処理により単離し、ローカル部分は、不透明なものとして扱われなければなりません。 DNSで検索される任意のドメイン名は、最初に、彼らはそのフォームに既にある場合を除きもしToASCII（）操作により、「アプリケーション（IDNA）で国際化ドメイン名」[RFC3490]で指定した形式に処理しなければなりません。ローカルの文字列と比較される任意のドメイン名は、有効性をチェックする必要があり、IDNAの3.4節で指定され、その後比較しなければなりません。
An SMTP client that receives the UTF8SMTP extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form. It MAY send a UTF-8 header [RFC5335] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as either ACE (ASCII Compatible Encoding) labels (as specified in IDNA [RFC3490]) or UTF-8 strings. All labels in domain parts of mailbox names which are IDNs (either UTF-8 or ACE strings) MUST be valid. If the original client submits a message to a Message Submission Server ("MSA") [RFC4409], it is the responsibility of the MSA that all domain labels are valid; otherwise, it is the original client's responsibility. The presence of the UTF8SMTP extension does not change the requirement of RFC 2821 that servers relaying mail MUST NOT attempt to parse, evaluate, or transform the local part in any way.
SMTPは、UTF-8形式でのように国際化された文字列をコマンド内EHLOコマンドに応答してUTF8SMTP拡張キーワードを受け取り、SMTPクライアントがメールボックス名を送信してもよいです。それは（もUTF-8でメールボックス名を含んでいてもよい）UTF-8ヘッダ[RFC5335]を送るかもしれ。これは、ACE（ASCII互換エンコーディング）ラベル（IDNA [RFC3490]で指定されるように）、またはUTF-8文字列のいずれかとしてSMTPコマンドまたはメッセージヘッダ内のメールボックス名のドメイン部分を送信することができます。 IDNのあるメールボックス名のドメイン部分のすべてのラベル（UTF-8またはACE文字列のいずれか）が有効である必要があります。元のクライアントは、メッセージの送信サーバー（「MSA」）[使いrfc4409]にメッセージを送信した場合、それはすべてのドメインラベルが有効であることをMSAの責任です。それ以外の場合は、元のクライアントの責任です。 UTF8SMTP拡張の存在がメールを中継サーバは、解析しようとすると、評価、または何らかの方法でローカル部分を変換してはならないことをRFC 2821の要件は変更されません。
If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP client MUST NOT transmit an internationalized address and MUST NOT transmit a mail message containing internationalized mail headers as described in [RFC5335] at any level within its MIME structure. (For this paragraph, the internationalized domain name in the form of ACE labels as specified in IDNA [RFC3490] is not considered as "internationalized".) Instead, if an SMTP client (SMTP sender) attempts to transfer an internationalized message and encounters a server that does not support the extension, it MUST make one of the following four choices:
UTF8SMTP SMTP拡張がサーバによって提供されていない場合に、SMTPクライアントは、国際アドレスを送信してはいけませんと[RFC5335]に記載されているように、そのMIME構造内の任意のレベルで国際メールヘッダーを含む電子メールメッセージを送信してはいけません。 （この段落では、IDNA [RFC3490]で指定されるようにACEラベルの形で国際化ドメイン名は、「国際」とはみなされない。）その代わりに、SMTPクライアント（SMTP送信者）は、国際化されたメッセージを転送しようと遭遇した場合拡張機能をサポートしていないサーバは、それは次の4つの選択肢のいずれかを行う必要があります。
1. If and only if the SMTP client (sender) is a Message Submission Server ("MSA") [RFC4409], it MAY, consistent with the general provisions for changes by such servers, rewrite the envelope, headers, or message material to make them entirely ASCII and consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822].
1. SMTPクライアント（送信者）がメッセージの送信サーバー（「MSA」）[使いrfc4409]である場合にのみ、それは、そのようなサーバによって変更のための一般規定と矛盾にエンベロープ、ヘッダー、またはメッセージの材料を書き換える可能性がある場合それら完全にASCIIと[RFC2821]およびRFC 2822 [RFC2822] RFC 2821の規定と矛盾します。
2. It may either reject the message during the SMTP transaction or accept the message and then generate and transmit a notification of non-deliverability. Such notification MUST be done as specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI delivery status notification (DSN) specification [RFC5337].
2.これは、SMTPトランザクション中にメッセージを拒否するか、メッセージを受け入れて、非デリバリーの通知を生成して送信することができるいずれか。そのような通知は、RFC 2821 [RFC2821]、RFC 3464 [RFC3464]で指定されるように行われ、EAI配達状態通知（DSN）仕様[RFC5337]なければなりません。
3. It may find an alternate route to the destination that permits UTF8SMTP. That route may be discovered by trying alternate Mail eXchanger (MX) hosts (using preference rules as specified in RFC 2821) or using other means available to the SMTP-sender.
3.それはUTF8SMTPを可能にする目的地までの代替ルートを見つけることができます。その経路は、（RFC 2821で指定されるように優先規則を使用して）、代替メール交換器（MX）ホストを試すか、SMTP送信者に利用可能な他の手段を用いて発見することができます。
4. If and only if ASCII addresses are available for all addresses that appear in the return path and the specific forward paths being attempted, it may downgrade the message to an all-ASCII form as specified in [Downgrade]. An ASCII address is considered to be "available" for a particular address if the original address in the envelope is in ASCII or if an ALT-ADDRESS parameter is specified for a UTF8SMTP address.
4. IfおよびASCIIアドレスがリターンパスに表示されるすべてのアドレスと試みている特定のフォワード・パスのために利用可能である場合にのみ、[ダウングレード]で指定されるように、それはすべて、ASCII形式にメッセージをダウングレードしてもよいです。 ASCIIアドレスはALT-ADDRESSパラメータがUTF8SMTPアドレスに指定されている場合は封筒の元のアドレスはASCIIである場合や、特定のアドレスのために「利用可能」であると考えられています。
The difference between choice 1 and choice 4 is that choice 1 is constrained by Message Submission [RFC4409], while choice 4 is constrained by [Downgrade].
選択肢1と選択肢4との間の差は、選択4 [ダウングレード]によって拘束されながら、選択1は、メッセージ提出[使いrfc4409]によって拘束されることです。
RFC 2821, Section 4.1.2, defines the syntax of a mailbox entirely in terms of ASCII characters, using the production for a mailbox and those productions on which it depends.
RFC 2821、セクション4.1.2には、メールボックスの生産とそれが依存するこれらの作品を使用して、ASCII文字の面で完全にメールボックスの構文を定義します。
The key changes made by this specification are, informally, to
この仕様で作られたキーの変更がに、非公式に、あります
o Change the definition of "sub-domain" to permit either the definition above or a UTF-8 string representing a DNS label that is conformant with IDNA [RFC3490].
O上記の定義やIDNA [RFC3490]に準拠あるDNSのラベルを表すUTF-8文字列のいずれかを可能にするために、「サブドメイン」の定義を変更します。
o Change the definition of "Atom" to permit either the definition above or a UTF-8 string. That string MUST NOT contain any of the ASCII characters (either graphics or controls) that are not permitted in "atext"; it is otherwise unrestricted.
O上記の定義またはUTF-8文字列のいずれかを可能にするために、「アトム」の定義を変更します。その文字列は「atext」で許可されていないASCII文字（グラフィックやコントロールのいずれか）のいずれかを含んではなりません。それは、そうでない場合は無制限です。
According to the description above, the syntax of an internationalized email mailbox name (address) is defined in ABNF [RFC5234] as follows.
上記の説明によれば、国際電子メールメールボックス名（アドレス）の構文は次のようにABNF [RFC5234]で定義されています。
uMailbox = uLocal-part "@" uDomain
; Replace Mailbox in RFC 2821, Section 4.1.2
uLocal-part = uDot-string / uQuoted-string ; MAY be case-sensitive ; Replace Local-part in RFC 2821, Section 4.1.2
uLocal部分= UDOT列/ uQuotedストリング。大文字と小文字を区別してもよい（MAY）。 RFC 2821、セクション4.1.2でローカル部分を交換してください
uDot-string = uAtom *("." uAtom) ; Replace Dot-string in RFC 2821, Section 4.1.2
UDOT文字列= uAtom *（uAtom ""）; RFC 2821、セクション4.1.2にドット文字列を置換
uAtom = 1*ucharacter ; Replace Atom in RFC 2821, Section 4.1.2
uAtom = 1 *キャラクター： RFC 2821、セクション4.1.2でアトムを交換してください
ucharacter = atext / UTF8-non-ascii
文字=テキスト/ UTF8-非ASCII
atext = <See Section 3.2.4 of RFC 2822>
atext = <RFC 2822のセクション3.2.4を参照してください>
uQuoted-string = DQUOTE *uqcontent DQUOTE ; Replace Quoted-string in RFC 2821, Section 4.1.2
uQuoted文字列= DQUOTE * uqcontentのDQUOTE。 RFC 2821に引用符で囲まれた文字列を交換し、4.1.2項
DQUOTE = <See appendix B.1 of RFC 5234>
DQUOTE = <RFC 5234の付録B.1を参照してください>
uqcontent = qcontent / UTF8-non-ascii
UQ内容=コンテンツ/ UTF-8非ASCII
qcontent = <See Section 3.2.5 of RFC 2822>
qcontent = <RFC 2822のセクション3.2.5を参照してください>
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal ; Replace Domain in RFC 2821, Section 4.1.2
uDomain =（ "" サブudomain 1 *（サブudomain））/アドレスリテラル。 RFC 2821でドメインを交換し、4.1.2項
address-literal = <See Section 4.1.2 of RFC 2822>
アドレスリテラル= <RFC 2822の4.1.2項を参照してください>
sub-udomain = uLet-dig [uLdh-str] ; Replace sub-domain in RFC 2821, Section 4.1.2
サブudomain = uLet-DIG [uLdh-STR]。 RFC 2821、セクション4.1.2にサブドメインを交換してください
uLet-dig = Let-dig / UTF8-non-ascii
uLetアップ=ライトアップ/ UTF8-非ASCII
Let-dig = <See Section 4.1.3 of RFC 2821>
ましょう-DIGは= <RFC 2821のセクション4.1.3を参照してください>
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig ; Replace Ldh-str in RFC 2821, Section 4.1.3
uLdh-STR = *（ALPHA / DIGIT / " - " / UTF8-非ASCII）uLet-掘ります。 RFC 2821、セクション4.1.3にLDH-STRを交換してください
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-非ASCII = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <See Section 4 of RFC 3629>
UTF8-2 = <RFC 3629のセクション4を参照してください>
UTF8-3 = <See Section 4 of RFC 3629>
UTF8-3 = <RFC 3629のセクション4を参照してください>
UTF8-4 = <See Section 4 of RFC 3629>
UTF8-4 = <RFC 3629のセクション4を参照してください>
The value of "uDomain" SHOULD be verified by applying the tests specified as part of IDNA [RFC3490]. If that verification fails, the email address with that uDomain MUST NOT be regarded as a valid email address.
「uDomain」の値は、IDNA [RFC3490]の一部として指定されたテストを適用することによって検証されるべきです。その検証が失敗した場合、そのuDomainとメールアドレスは、有効な電子メールアドレスと見なされてはなりません。
If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and RCPT commands is extended to support the optional esmtp-keyword "ALT-ADDRESS". That keyword specifies an alternate all-ASCII address that may be used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value, which is defined below).
UTF8SMTP拡張が提供されている場合は、SMTP MAILおよびRCPTコマンドの構文は、オプションのESMTPキーワード「ALT-ADDRESS」をサポートするように拡張されます。そのキーワードは、ダウングレードするときに使用することができる代替すべて-ASCIIアドレスを指定します。 ALTアドレスESMTPキーワードが使用される場合、それは（以下に定義されるALT-ADDRESS-ESMTP値を、）関連したESMTP値を持たなければなりません。
While it may be tempting to consider ALT-ADDRESS as a general-purpose second-chance address, such behavior is not defined here. Instead, in this specification ALT-ADDRESS only has meaning when the associated primary address is non-ASCII and the message is downgraded. This restriction allows for future extension of the specification even though no such extensions are currently anticipated.
それは汎用のセカンドチャンスアドレスとしてALT-ADDRESSを検討したくてもよいが、そのような行動は、ここで定義されていません。代わりに、関連付けられたプライマリアドレスが非ASCIIであり、メッセージが格下げされたときにのみ意味があり、この仕様のALT-ADDRESSインチこの制限は、そのような拡張は、現在予想されていないにもかかわらず、仕様の将来の拡張が可能になります。
Based on the definition of mail-parameters in [RFC2821], the ALT-ADDRESS parameter usage in the commands of MAIL and RCPT is defined as follows. The following definitions are given in the same format as used in RFC 2821.
次のように[RFC2821]でメールのパラメータ、MAILとRCPTコマンドの中のALT-ADDRESSパラメータの使用の定義に基づいて定義されます。以下の定義は、RFC 2821で使用したのと同じ形式で与えられます。
"MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF
; Update the MAIL command in RFC 2821, Section 4.1.1.2.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param> in RFC 2821.
"RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" / uForward-path) [ SP Rcpt-parameters ] CRLF ; Update RCPT command in RFC 2821, Section 4.1.1.3. ; A new parameter defined by the ABNF non-terminal ; <ALT-ADDRESS-parameter> is added. It complies ; with the syntax specified for <esmtp-param>. ; uDomain is defined in Section 3.3 of this document.
"RCPT TO："（ "<uDomain @ポストマスタ" ">" / "<ポストマスタ>" / uForwardパス）[SP RCPTパラメータ] CRLF。 RFC 2821でのRCPTコマンドを更新し、セクション4.1.1.3。 ; ABNF非終端によって定義された新しいパラメータ。 <ALT-ADDRESSパラメータ>追加されます。それは準拠します。 <ESMTP-param>のために指定された構文を持ちます。 ; uDomainは、このドキュメントのセクション3.3で定義されています。
uReverse-path = uPath ; Replace Reverse-path in RFC 2821, Section 4.1.2.
uReverseパス= uPath。 RFC 2821、セクション4.1.2にリバースパスを交換してください。
uForward-path = uPath ; Replace Forward-path in RFC 2821, Section 4.1.2.
uForwardパス= uPath。 RFC 2821、セクション4.1.2にフォワード・パスを交換してください。
uPath = "<" [ A-d-l ":" ] uMailbox ">" ; Replace Path in RFC 2821, Section 4.1.2. ; uMailbox is defined in Section 3.3 of this document.
uPath = "<" [A-D-L "："] uMailbox ">"。 RFC 2821、セクション4.1.2でパスを交換してください。 ; uMailboxは、このドキュメントのセクション3.3で定義されています。
A-d-l = <See Section 4.1.2 of RFC 2821>
-D-L = <RFC 2821のセクション4.1.2を参照>
ALT-ADDRESS-parameter = "ALT-ADDRESS=" ALT-ADDRESS-value
ALT-ADDRESSパラメータ= "ALT-ADDRESS =" ALT-ADDRESS値
ALT-ADDRESS-value = xtext ; The value is a mailbox name encoded as xtext.
ALT-ADDRESS値= XTEXT。値はXTEXTとしてエンコードされたメールボックス名です。
xtext = <See Section 4.2 of RFC 3461>
XTEXT = <RFC 3461のセクション4.2を参照してください>
The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email address before xtext encoding.
ALT-ADDRESSパラメータは、一度任意のMAILやRCPTコマンドでより多く見えてはいけません。 ALT-ADDRESS-ESMTP値はXTEXT符号化前のすべての-ASCIIのメールアドレスでなければなりません。
An "internationalized message" as defined in the appendix of this specification MUST NOT be sent to an SMTP server that does not support UTF8SMTP. Such a message MAY be rejected by a server if it lacks ALT-ADDRESSes as discussed in Section 3.2 of this specification.
この仕様の付録で定義された「国際化されたメッセージは、」UTF8SMTPをサポートしていないSMTPサーバーに送ってはいけません。この仕様書の3.2節で述べたように、それはALT-アドレスが不足している場合、このようなメッセージがサーバーによって拒否されるかもしれません。
The three-digit reply codes used in this section are consistent with their meanings as defined in RFC 2821.
RFC 2821で定義されるように、このセクションで使用される3桁の応答コードは、その意味と一致しています。
When messages are rejected because the RCPT command requires an ALT-ADDRESS, the response code 553 is used with the meaning "mailbox name not allowed". When messages are rejected for other reasons, such as the MAIL command requiring an ALT-ADDRESS, the response code 550 is used with the meaning "mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], response code "X.6.7" [RFC5248] is used, meaning that "The ALT-ADDRESS is required but not specified".
RCPTコマンドはALT-ADDRESSを必要とするため、メッセージが拒否された場合、応答コード553は、意味の「許可されていないメールボックス名」で使用されています。メッセージはALT-ADDRESSを必要とするようなMAILコマンドのような他の理由で拒否された場合、レスポンスコード550が意味「利用できないメールボックス」とともに使用されます。サーバが強化されたメールシステムステータスコード[RFC3463]、応答コード「X.6.7」をサポートしている場合は、[RFC5248]「ALT-ADDRESSが必要ですが指定されていない」ことを意味し、使用されています。
If the response code is issued after the final "." of the DATA command, the response code "554" is used with the meaning "Transaction failed". When the server supports enhanced mail system status codes [RFC3463], response code "X.6.9" [RFC5248] is used, meaning that "UTF8SMTP downgrade failed".
応答コードは、最後の後に発行されている場合は「」 DATAコマンドの応答コード「554」は、「トランザクションが失敗しました」の意味で使用されています。サーバが強化されたメールシステムステータスコード[RFC3463]、応答コード「X.6.9」をサポートしている場合は、[RFC5248]「UTF8SMTPのダウングレードに失敗した」ことを意味し、使用されています。
There is no ESMTP parameter to assert that a message is an internationalized message. An SMTP server that requires accurate knowledge of whether a message is internationalized is required to parse all message header fields and MIME header fields in the message body.
メッセージが国際化されたメッセージであることを主張するいかなるESMTPパラメータはありません。国際化されたメッセージがメッセージ本体内のすべてのメッセージヘッダフィールドおよびMIMEヘッダフィールドを解析する必要があるかどうかの正確な知識を必要とするSMTPサーバ。
While this specification requires that servers support the 8BITMIME extension [RFC1652] to ensure that servers have adequate handling capability for 8-bit data and to avoid a number of complex encoding problems, the use of internationalized addresses obviously does not require non-ASCII body parts in the MIME message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME parameter if that is appropriate given the body content or, with the BODY=BINARYMIME parameter, if the server advertises BINARYMIME [RFC3030] and that is appropriate.
この仕様は、サーバーが8BITMIME拡張[RFC1652]サーバは8ビットのデータのための十分な処理能力を持っていることを確実にするために、複雑なエンコーディングの問題の数、非ASCII本体の部品を必要としない、明らかに国際アドレスの使用を避けることをサポートしていることが必要ですがMIMEメッセージインチすなわちBODY = BINARYMIMEパラメータを使用して、身体のコンテンツ所与適切である場合、またはサーバがBINARYMIME [RFC3030]をアドバタイズし、それが適切であるかどうUTF8SMTP拡張は、BODY = 8BITMIMEパラメータと共に使用することができます。
Assuming that the server advertises UTF8SMTP and 8BITMIME, and receives at least one non-ASCII address, with or without ALT-ADDRESS, the precise interpretation of 'No BODY parameter', "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is:
「いいえBODYパラメータ」の正確な解釈は、「BODY = 8BITMIME」、ALT-ADDRESSの有無にかかわらず、サーバがUTF8SMTPと8BITMIMEをアドバタイズし、少なくとも一つの非ASCIIアドレスを受けると仮定すると、「BODY = BINARYMIME」にMAILコマンドは次のとおりです。
1. If there is no BODY parameter, the header contains UTF-8 characters, but all the body parts are in ASCII (possibly as the result of a content-transfer-encoding).
1.ない身体パラメータが存在しない場合、ヘッダは、UTF-8文字が含まれているが、すべての身体の部分は、（おそらく、コンテンツ転送エンコードの結果として）ASCIIです。
2. If a BODY=8BITMIME parameter is present, the header contains UTF-8 characters, and some or all of the body parts contain 8-bit line-oriented data.
BODY = 8BITMIMEパラメータが存在する場合2.ヘッダはUTF-8文字が含まれており、体の部分のいくつかまたは全ては、8ビットの行指向のデータを含みます。
3. If a BODY=BINARYMIME parameter is present, the header contains UTF-8 characters, and some or all body parts contain binary data without restriction as to line lengths or delimiters.
3. BODY = BINARYMIMEパラメータが存在する場合、ヘッダは、UTF-8文字が含まれており、長さまたは区切り文字を整列するように一部またはすべての身体の部分は、特に制限はなく、バイナリデータを含みます。
The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that, when RFC 2821 specifies a mailbox, this specification expects UTF-8 to be used for the entire string; when RFC 2821 specifies a domain name, the name SHOULD be in the form of ACE labels if its raw form is non-ASCII.
メール輸送過程で運ばれた情報は、MAILとRCPTコマンドとそれらに拡張された代替品に加えて、さまざまなコンテキストでのアドレス（「メールボックス」）とドメイン名を必要とします。一般的に、ルールは、RFC 2821のメールボックスを指定した場合、本明細書は、UTF-8文字列全体に使用されることを期待する、ということです。 RFC 2821には、ドメイン名を指定した場合にその生の形式が非ASCIIであれば、名前はACEラベルの形式でなければなりません。
The following subsections list and discuss all of the relevant cases.
以下のサブセクションでは、リストと関連する例すべてを議論します。
When an SMTP connection is opened, the server normally sends a "greeting" response consisting of the 220 response code and some information. The client then sends the EHLO command. Since the client cannot know whether the server supports UTF8SMTP until after it receives the response from EHLO, any domain names that appear in this dialogue, or in responses to EHLO, MUST be in the hostname form, i.e., internationalized ones MUST be in the form of ACE labels.
SMTP接続が開かれたとき、サーバは、通常、220応答コードといくつかの情報からなる「挨拶」応答を送信します。次に、クライアントはEHLOコマンドを送信します。クライアントは、サーバがEHLOからの応答を受信するまでUTF8SMTPをサポートしているかどうかを知ることができないので、このダイアログに表示される、またはEHLOへの応答内の任意のドメイン名は、ホスト名の形式でなければなりません、すなわち、国際ものが形式でなければなりませんACEラベルの。
Organizations often authorize multiple servers to accept mail addressed to them. For example, the organization may itself operate more than one server, and may also or instead have an agreement with other organizations to accept mail as a backup. Authorized servers are generally listed in MX records as described in RFC 2821. When more than one server accepts mail for the domain-part of a mailbox, it is strongly advised that either all or none of them support the UTF8SMTP extension. Otherwise, surprising downgrades can happen during temporary failures, which users might perceive as a serious reliability issue.
組織は、多くの場合、それら宛のメールを受け入れるように、複数のサーバーを承認します。たとえば、組織自体が複数のサーバを動作することができ、また、または代わりに、バックアップとしてメールを受け付けるために、他の機関との契約を有していても良いです。複数のサーバーがメールボックスのドメイン一部のメールを受け付けるとRFC 2821に記載され承認されたサーバーは、一般的にMXレコードにリストされている、強く、それらのすべてまたはnoneのいずれかがUTF8SMTP拡張をサポートすることをお勧めします。そうでなければ、意外な格下げは、ユーザーが深刻な信頼性の問題として認識する可能性がある、一時的な障害時に発生する可能性があります。
When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content. "Time stamp" or "Received" appears in the form of "Received:" lines. The most important use of Received: lines is for debugging mail faults. When the delivery SMTP server makes the "final delivery" of a message, it inserts a Return-path line at the beginning of the mail data. The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For the trace information, this memo updates the time stamp line and the return path line [RFC2821] formally defined as follows:
SMTPサーバが配信またはさらなる処理のためのメッセージを受信すると、メッセージの内容の先頭にトレース（「タイムスタンプ」または「受信」）の情報を挿入しなければなりません。ライン：「タイムスタンプ」または「受信」を「受信」の形式で表示されます。受信の最も重要な用途：行は、メール障害をデバッグするためです。配信SMTPサーバがメッセージの「最終配信」を作る際には、メールデータの先頭にリターンパス行を挿入します。リターンパスの主な目的は、非送達または他のメールシステム障害を示すメッセージが送信されるべきアドレスを指定することです。トレース情報については、このメモは、次のように正式に定義[RFC2821]タイムスタンプラインとリターンパスラインを更新します。
uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF> ; Replaces Return-path-line in Section 4.4 of RFC 2821 ; uReverse-path is defined in Section 3.3 of this document
uReturnパスライン=「リターンパスを：」FWS uReverseパス<CRLF>。 RFC 2821のセクション4.4のリターン・パス・ラインを置き換えます。 uReverseパスは、このドキュメントのセクション3.3で定義され
uTime-stamp-line = "Received:" FWS uStamp <CRLF> ; Replaces Time-stamp-line in Section 4.4 of RFC 2821
UTIMEスタンプラインは= "受信：" FWS uStamp <CRLF>。 RFC 2821のセクション4.4でタイムスタンプ行を置き換え
uStamp = From-domain By-domain uOpt-info ";" FWS date-time ; Replaces Stamp in Section 4.4 of RFC 2821
uStamp =からドメインuOpt-INFO-ドメインによって ";" FWS日時; RFC 2821のセクション4.4でスタンプ置き換え
uOpt-info = [Via] [With] [ID] [uFor] ; Replaces Opt-info in Section 4.4 of RFC 2821 ; The protocol value for With will allow a UTF8SMTP value
uOpt-情報= [経由] [付] [ID] [uFor]。 RFC 2821のセクション4.4でオプト情報を置き換えます。プロトコル値はUTF8SMTP値を許可します
uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS ; Replaces For in Section 4.4 of RFC 2821 ; uPath and uMailbox are defined in Sections 2.4 and ; 2.3, respectively, of this document
（FWS（uPath / uMailbox））CFWS "FOR" uFor =; RFC 2821のセクション4.4にするために置き換えます。 uPathとuMailboxは、セクション2.4とで定義されています。このドキュメントのそれぞれ2.3、
Note: The FOR parameter has been changed to match the definition in [RFC2821bis], permitting only one address in the For clause. The group working on that document reached mailing list consensus that the syntax in [RFC2821] that permitted more than one address was simply a mistake.
注意：パラメータFOR句の場合で1つのアドレスのみを許可する、[RFC2821bis]で定義と一致するように変更されました。その文書にワーキンググループは、複数のアドレスを許可[RFC2821]の文法は、単に間違いだったことをメーリングリストの合意に達しました。
Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII domain names may be used, internationalized domain names in Received fields MUST be transmitted in the form of ACE labels. The protocol value of the WITH clause when this extension is used is one of the UTF8SMTP values specified in the "IANA Considerations" section of this document.
「uFor」句と非ASCIIドメイン名を使用することができる「uReverseパス」値を除いて、受信された分野で国際化ドメイン名は、ACEラベルの形で送信されなければなりません。この拡張を使用するWITH句のプロトコル値は、この文書の「IANAの考慮事項」の項で指定さUTF8SMTP値の一つです。
If the client issues a RCPT command containing non-ASCII characters, the SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 response codes.
クライアントは、非ASCII文字を含むRCPTコマンドを発行すると、SMTPサーバは、251と551の応答コードに関連付けられているメールアドレスにUTF-8文字の使用を許可されています。
If an SMTP client follows this specification and sends any RCPT commands containing non-ASCII addresses, it MUST be able to accept and process 251 or 551 responses containing UTF-8 email addresses. If a given RCPT command does not include a non-ASCII envelope address, the server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain addresses.
SMTPクライアントがこの仕様を以下の非ASCIIアドレスを含むすべてのRCPTコマンドを送信した場合、UTF-8のメールアドレスを含む251か551の応答を受け入れて処理できなければなりません。与えられたRCPTコマンドが非ASCIIエンベロープアドレスが含まれていない場合は、サーバーは非ASCIIメールボックスを含む251か551応答を返してはなりません。代わりに、アドレスが含まれていない250や550レスポンスにそのような応答を変換する必要があります。
If the VRFY and EXPN commands are transmitted with an optional parameter "UTF8REPLY", it indicates the client can accept UTF-8 strings in replies from those commands. This allows the server to use UTF-8 strings in mailbox names and full names that occur in replies without concern that the client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies from the VRFY and EXPN commands that contain UTF-8 strings. However, the SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter. Most replies do not require that a mailbox name be included in the returned text, and therefore UTF-8 is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox, making the provisions of this section important.
VRFYとEXPNコマンドは、オプションのパラメータ「UTF8REPLY」で送信されている場合、それは、クライアントがそれらのコマンドからの返信にUTF-8文字列を受け入れることを示します。これは、サーバーがメールボックス名とクライアントがそれらによって混同される可能性があることを気にせずに応答で発生フルネームでUTF-8文字列を使用することができます。この仕様に準拠したSMTPクライアントが受け入れ、正しくUTF-8文字列を含むVRFYとEXPNコマンドからの応答を処理しなければなりません。 SMTPクライアントは、特にこのパラメータを送信することにより、このような応答を許可しない場合は、SMTPサーバが応答でUTF-8文字列を使用してはなりません。ほとんどの回答は、メールボックス名が返されたテキストに含まれるので、UTF-8は、それらに必要とされていないことを必要としません。いくつかの回答、VRFYとEXPNコマンドの実行が成功したときの結果、特にこれらは、重要なこの節の規定を作り、メールボックスが含まれません。
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
（VRFY）を確認し、EXPAND（EXPN）コマンドの構文は次のように変更されています。
"VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF
; uLocal-part and uMailbox are defined in
; Section 3.3 of this document.
"EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF ; uLocal-part and uMailbox are defined in ; Section 3.3 of this document.
"EXPN" SP（uLocal部分/ uMailbox）[SP "UTF8REPLY"] CRLF。 uLocal部分とuMailboxはで定義されています。このドキュメントのセクション3.3。
The "UTF8REPLY" parameter does not use a value. If the reply to a VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP client does not use the "UTF8REPLY" parameter, then the server MUST use either the response code 252 or 550. Response code 252, defined in [RFC2821], means "Cannot VRFY user, but will accept the message and attempt the delivery". Response code 550, also defined in [RFC2821], means "Requested action not taken: mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], the enhanced response code as specified below is used. Using the "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that command only.
「UTF8REPLY」パラメータの値を使用しません。回答は（VRFY）を確認するか、EXPAND（EXPN）コマンドはUTF-8が必要ですが、SMTPクライアントが「UTF8REPLY」パラメータを使用していない場合、サーバは、応答コード252または550レスポンスコード252のいずれかを使用しなければなりません[RFC2821]で定義され、「VRFYユーザーことはできませんが、メッセージを受け入れ、配信を試みます」という意味。また、[RFC2821]で定義された応答コード550は、「：利用できないメールボックスに要求されたアクションは取られない」を意味します。以下に指定されるように、サーバは、拡張メールシステムステータスコード[RFC3463]、拡張応答コードをサポートしている場合に使用されます。 VERIFY（VRFY）と「UTF8REPLY」パラメータを使用するか、EXPAND（EXPN）コマンドは、そのコマンドのみにUTF-8の応答を可能にします。
If a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms:
通常の成功応答（すなわち、250）が返された場合、応答は、ユーザーのフルネームを含むことができ、ユーザーのメールボックスを含まなければなりません。これは、次のいずれかの形式でなければなりません。
User Name <uMailbox>
; uMailbox is defined in Section 3.3 of this document.
; User Name can contain non-ASCII characters.
uMailbox ; uMailbox is defined in Section 3.3 of this document.
uMailbox; uMailboxは、このドキュメントのセクション3.3で定義されています。
If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in the reply, and the server supports enhanced mail system status codes [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" [RFC5248], meaning "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the client".
SMTP応答がUTF-8文字列が必要ですが、UTF-8が応答で許可されていませんし、サーバーが強化されたメールシステムステータスコード[RFC3463]をサポートしている場合は、強化された応答コードは、いずれかの「X.6.8」または「X.6.10です『UTF-8文字列を含む応答がメールボックス名を表示するために必要ですが、応答の形がクライアントによって許可されていない」という意味[RFC5248]、』。
If the SMTP client does not support the UTF8SMTP extension, but receives a UTF-8 string in a reply, it may not be able to properly report the reply to the user, and some clients might crash. Internationalized messages in replies are only allowed in the commands under the situations described above. Under any other circumstances, UTF-8 text MUST NOT appear in the reply.
SMTPクライアントがUTF8SMTP拡張をサポートしていますが、返信にUTF-8文字列を受信しない場合は、適切にユーザーに返信を報告することができないかもしれない、といくつかのクライアントがクラッシュする可能性があります。回答では国際化されたメッセージは、上記のような状況の下でのコマンドで許可されています。他の状況下では、UTF-8のテキストは、回答に現れてはいけません。
Although UTF-8 is needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 for any other purposes. SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section.
UTF-8は、このセクションで指定されたルールの下での応答に電子メールアドレスを表現するために必要であるが、この拡張機能は、他の目的のためにUTF-8の使用を許可していません。 SMTPサーバーでは、特にこのセクションでは許可限られた場合を除いて回答に非ASCII文字を含んではいけません。
IANA has added a new value "UTF8SMTP" to the SMTP Service Extension subregistry of the Mail Parameters registry, according to the following data:
IANAは、次のデータによると、メールのパラメータレジストリのSMTPサービス拡張副登録に新しい値「UTF8SMTP」を追加しました：
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| UTF8SMTP | Internationalized email address | [RFC5336] |
+----------+---------------------------------+-----------+
This document adds new values to the SMTP Enhanced Status Code subregistry of the Mail Parameters registry, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and being based on [RFC5248]. The registration data is as follows:
この文書は、セクション3.5と、この文書の3.7.4.2でのガイダンスに従って、メールのパラメータレジストリのSMTP拡張状態コードの副登録に新しい値を追加し、[RFC5248]に基づいています。次のように登録データは以下のとおりです。
Code: X.6.7 Sample Text: The ALT-ADDRESS is required but not specified Associated basic status code: 553, 550 Description: This indicates the reception of a MAIL or RCPT command that required an ALT-ADDRESS parameter but such parameter was not present. Defined: RFC 5336 (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.7サンプルテキスト：ALT-ADDRESSは、関連する基本的なステータスコードを指定し必要ないが：553、550説明：これは、ALT-ADDRESSパラメータを必要MAILまたはRCPTコマンドを受信したことを示しているが、このようなパラメータが存在しませんでした。定義された：RFC 5336（実験トラック）投稿者：Jiankang YAO変更コントローラ：IESG。
Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the client Associated basic status code: 553, 550 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the client. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.8サンプルテキスト：UTF-8文字列の応答が必要ですが、クライアント関連する基本的なステータスコードによって許可されていない：553、550説明：これは、UTF-8文字列を含む応答がメールボックス名を表示するために必要であることを示していますが、応答の形式は、クライアントによって許可されていません。定義された：RFC 5336.（実験トラック）投稿者：Jiankang YAO変更コントローラ：IESG。
Code: X.6.9 Sample Text: UTF8SMTP downgrade failed Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.9サンプルテキスト：UTF8SMTP格下げは、関連する基本的なステータスコードを失敗しました：550説明：これは、最後の後に失敗し、そのトランザクションを示します「」 DATAコマンドの。定義された：RFC 5336.（実験トラック）投稿者：Jiankang YAO変更コントローラ：IESG。
Code: X.6.10 Sample Text: UTF-8 string reply is required, but not permitted by the client Associated basic status code: 252 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the client. Defined: RFC 5336. (Experimental track) Submitter: Jiankang YAO Change controller: IESG.
コード：X.6.10サンプルテキスト：UTF-8文字列の応答が必要ですが、基本的なステータスコード関連するクライアントによって許可されていません：252説明：これは、UTF-8文字列を含む回答がメールボックス名を表示するために必要であることを示しているが、応答の形式は、クライアントによって許可されていません。定義された：RFC 5336.（実験トラック）投稿者：Jiankang YAO変更コントローラ：IESG。
The "Mail Transmission Types" registry under the Mail Parameters registry is requested to be updated to include the following new entries:
メールのパラメータレジストリの下に「メール送信タイプ」のレジストリは、次の新しいエントリを含むように更新することが要求されます。
+---------------+----------------------------+----------------------+
| WITH protocol | Description | Reference |
| types | | |
+---------------+----------------------------+----------------------+
| UTF8SMTP | UTF8SMTP with Service | [RFC5336] |
| | Extensions | |
| UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFC5336] |
| UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFC5336] |
| UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] |
| | STARTTLS and SMTP AUTH | [RFC5336] |
+---------------+----------------------------+----------------------+
See the extended security considerations discussion in the framework document [RFC4952].
フレームワークドキュメント[RFC4952]の拡張セキュリティの考慮事項の説明を参照してください。
Much of the text in the initial version of this specification was derived or copied from [Emailaddr] with the permission of the author. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the WG and design team. Those contributions include material from John C Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here.
この仕様の初期バージョンでは、テキストの多くは、著者の許可を得て派生または[EMAILADDR]からコピーされました。重要なコメントや提案は暁東LEE、ナイ・ウェン・スー、Yangwoo KO、芳郎米谷、およびJETチームの他のメンバーから受信し、仕様に組み込まれました。追加の重要なコメントや提案、そして多くの場合、特定のテキストは、WG及び設計チームの多くのメンバーによって寄与されました。これらの貢献はジョン・C Klensin、チャールズリンジー、デイブ・クロッカー、ハラルド・トバイット・アルベストランド、マルコス・サンス、クリス・ニューマン、マーティンDuerst、エドモンチャン、トニー・フィンチ、カリHurtta、ランドールGellens、フランクEllermann、アレクセイ・メルニコフ、ピート・レズニック、Sからの材料を含みます。Moonesamy、Soobokリー、ショーン・スティール、アルフレッドHoenes、ミゲル・ガルシア、マグヌスウェスター、そしてラースエッゲルト。もちろん、個人のいずれもが、必ずしもここに表さアイデアの組み合わせの責任ではありません。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII]米国規格協会（アメリカ規格協会の旧米国）、「情報交換用米国コード」、ANSI X3.4-1968、1968。
[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月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[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月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。
[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月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC5248]ハンセン、T.およびJ. Klensin、 "SMTP拡張メールシステムステータスコードのレジストリ"、BCP 138、RFC 5248、2008年6月。
[RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]アベル、Y.、エド。、 "国際電子メールヘッダ"、RFC 5335、2008年9月。
[RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
[RFC5337]ニューマン、C.とA.メルニコフ、エド。、 "国際配送状況や処分通知"、RFC 5337、2008年9月。
[Downgrade] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
[ダウングレード]藤原、K.とY.米谷、「メールアドレスの国際化のためのメカニズムのダウングレード」、進歩、2008年7月に作業。
[Emailaddr] Klensin, J., "Internationalization of Email Addresses", Work in Progress, July 2005.
[EMAILADDR] Klensin、J.、 "メールアドレスの国際化"、進歩、2005年7月での作業。
[RFC0974] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
[RFC0974]ヤマウズラ、C.、 "メール・ルーティングとドメインシステム"、RFC 974、1986年1月。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033]マイヤーズ、J.、 "ローカルメール転送プロトコル"、RFC 2033、1996年10月。
[RFC2821bis] Klensin, J., "Simple Mail Transfer Protocol", Work in Progress, July 2008.
[RFC2821bis] Klensin、J.、 "簡易メール転送プロトコル"、進歩、2008年7月に作業。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[RFC3030]ヴォードルイユ、G.、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954] Siemborski、R.、エド。そして、A.メルニコフ、エド。、 "認証のためのSMTPサービス拡張子"、RFC 4954、2007年7月。
Appendix A. Material Updating
付録A.資料の更新
RFC 4952, the overview and framework document covering this set of extensions for internationalized email, was completed before this specification, which specifies a particular part of the protocol set. This appendix, which is normative, contains material that would have been incorporated into RFC 4952 had it been delayed until the work described in the rest of this specification was completed. This material should be included in any update to RFC 4952.
RFC 4952は、国際化電子メール用の拡張機能のセットをカバーする概要と枠組み文書は、プロトコルセットの特定の部分を指定し、この仕様、前に完了しました。規範的であるこの付録では、この仕様の残りの部分で説明した作業が完了するまで、それが遅れていたRFC 4952に組み込まれていたであろう材料が含まれています。この材料は、RFC 4952へのアップデートに含まれるべきです。
A.1. Conventional Message and Internationalized Message
A.1。従来のメッセージと、国際化されたメッセージ
o A conventional message is one that does not use any extension defined in this document or in the UTF-8 header specification [RFC5335], and which is strictly conformant to RFC 2822 [RFC2822].
O従来のメッセージは、この文書またはUTF-8ヘッダー仕様[RFC5335]で定義された任意の拡張子を使用していないものであり、RFC 2822 [RFC2822]に厳密に準拠しています。
o An internationalized message is a message utilizing one or more of the extensions defined in this specification or in the UTF-8 header specification [RFC5335], so that it is no longer conformant to the RFC 2822 specification of a message.
それはもはやメッセージのRFC 2822仕様に準拠しないようにO国際化メッセージは、本明細書またはUTF-8ヘッダー仕様[RFC5335]で定義された拡張機能の一つ以上を利用したメッセージです。
A.2. LMTP
A.2。 LMTP
LMTP [RFC2033] may be used as the final delivery agent. In such cases, LMTP may be arranged to deliver the mail to the mail store. The mail store may not have UTF8SMTP capability. LMTP needs to be updated to deal with these situations.
LMTP [RFC2033]は、最終的な送達剤として使用することができます。このような場合には、LMTPは、メール・ストアにメールを配信するように構成することができます。メールストアはUTF8SMTP機能を持っていないかもしれません。 LMTPは、これらの状況に対処するために更新する必要があります。
A.3. SMTP Service Extension for DSNs
A.3。 DSNのためのSMTPサービス拡張
The existing Draft Standard regarding delivery status notifications (DSNs) [RFC3461] is limited to ASCII text in the machine readable portions of the protocol. "International Delivery Status and Disposition Notifications" [RFC5337] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the UTF8SMTP and the DSN extension, that server MUST implement EAI DSN [RFC5337] including support for the ORCPT parameter.
既存の標準案に関する配信状態通知（DSN）[RFC3461]はプロトコルの機械可読部分におけるASCIIテキストに限定されます。 「国際配送状況や処分通知」[RFC5337]はとても非ASCII文字を元の受信者のアドレスが正しくも、ダウングレード後に保存することができ、国際メールアドレスの新しいアドレスタイプを追加します。 SMTPサーバはUTF8SMTPとDSN拡張の両方をアドバタイズする場合、そのサーバはORCPTパラメータのサポートを含む、EAI DSN [RFC5337]を実装しなければなりません。
A.4. Implementation Advice
A.4。実装のアドバイス
In the absence of this extension, SMTP clients and servers are constrained to using only those addresses permitted by RFC 2821. The local parts of those addresses MAY be made up of any ASCII characters, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization SHOULD be phased out as this extension becomes widely deployed, but backward-compatibility considerations require that it continue to be supported.
そこに指定されているそれらのいくつかを引用しなければならないが、この拡張機能がない場合には、SMTPクライアントとサーバは、これらのアドレスのローカル部分は任意のASCII文字で構成されていてもよいRFC 2821によって許可アドレスだけを使用するように制約されています。非ASCII文字を近似するために引用符で囲まれた文字列の中にASCII文字（文字、バックスペース、および他の文字）を重ね打ち使用していくつかのシステムでは長い歴史があることを国際化文脈で注目すべきです。国際化のこの形式は広く展開となり、この延長として段階的に廃止されるべきであるが、下位互換性の考慮事項は、引き続きサポートされている必要があります。
A.5. Applicability of SMTP Extension to Additional Uses
A.5。その他の使用へのSMTP拡張の適用
Among other protocol changes, the SMTP extension allows an optional alternate address to be supplied with the MAIL and RCPT commands. For the purposes of this set of specifications, this alternate address only has meaning when the primary address contains UTF-8 characters and the message is downgraded. While it may be tempting to consider the alternate address as a general-purpose second-chance address to be used whenever the primary address is rejected, such behavior is not defined here. This restriction allows for future extensions to be developed which create such a general-purpose second-chance address, although no specific work on such an extension is currently anticipated. Note that any such extension needs to consider the question of what the [RFC0974] sequencing rules mean when different possible servers support different sets of ESMTP options (or, in this case, addresses). The answer to this question may also imply updates to [RFC2821].
他のプロトコルの変更のうち、SMTP拡張は、オプションの代替アドレスは、MAILとRCPTコマンドが供給されることを可能にします。プライマリアドレスは、UTF-8文字が含まれていると、メッセージが格下げされたときの仕様のこのセットのために、この代替アドレスにのみ意味を持ちます。それはプライマリアドレスが拒否されるたびに使用される汎用のセカンドチャンスアドレスとして代替アドレスを検討したくてもよいが、そのような行動は、ここで定義されていません。そのような拡張には具体的な作業は、現在予想されていないが、この制限は、汎用のセカンドチャンスアドレスを作成する開発される将来の拡張が可能になります。どのような拡張が可能な異なるサーバがESMTPオプション（または、この場合は、アドレス）の異なるセットをサポートしている場合、[RFC0974]のシーケンシングルールが何を意味するかの問題を検討する必要があることに注意してください。この質問への答えはまた、[RFC2821]への更新を意味し得ます。
Authors' Addresses
著者のアドレス
Jiankang YAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
J私の健康Y AO（エディタ）CNNICの4番南4TH通り、Z肉眼インチ北京
Phone: +86 10 58813007 EMail: yaojk@cnnic.cn
電話：+86 10 58813007 Eメール：yaojk@cnnic.cn
Wei MAO (editor) CNNIC No.4 South 4th Street, Zhongguancun Beijing
魏真央（エディタ）CNNICの4番南4TH通り、Zマクロインチ北京
Phone: +86 10 58812230 EMail: maowei_ietf@cnnic.cn
電話：+86 10 58812230 Eメール：maowei_ietf@cnnic.cn
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に情報を記述してください。