Network Working Group P. Resnick
Request for Comments: 5738 Qualcomm Incorporated
Updates: 3501 C. Newman
Category: Experimental Sun Microsystems
March 2010
IMAP Support for UTF-8
Abstract
抽象
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.
この仕様は、ユーザー名、メールアドレス、およびメッセージのヘッダーにUTF-8でエンコードされた国際文字をサポートするためのインターネットメッセージアクセスプロトコルVersion 4rev1（IMAP4rev1の）を拡張します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5738.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5738で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. UTF8=ACCEPT IMAP Capability . . . . . . . . . . . . . . . . . 3
3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3
3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5
3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5
3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6
3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6
3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6
4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7
5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7
6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7
7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 8
8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8
9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 14
Appendix B. Examples Demonstrating Relationships between
UTF8= Capabilities . . . . . . . . . . . . . . . . . 15
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
This specification extends IMAP4rev1 [RFC3501] to permit UTF-8 [RFC3629] in headers as described in "Internationalized Email Headers" [RFC5335]. It also adds a mechanism to support mailbox names, login names, and passwords using the UTF-8 charset. This specification creates five new IMAP capabilities to allow servers to advertise these new extensions, along with two new IMAP LIST selection options and a new IMAP LIST return option.
本明細書では、 "国際電子メールヘッダ" [RFC5335]に記載されているようにヘッダにUTF-8 [RFC3629]を可能にするためのIMAP4rev1 [RFC3501]を延びています。また、UTF-8文字セットを使用してメールボックス名、ログイン名、およびパスワードをサポートするためのメカニズムを追加します。この仕様は、2つの新しいIMAPリスト選択オプションと新しいIMAPのLISTリターンオプションと一緒に、サーバはこれらの新しい拡張機能を宣伝できるようにするために5つの新しいIMAP機能を作成します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、およびこのドキュメントの「要件レベルを示すためのRFCsにおける使用のためのキーワード」で定義されているように解釈されるべきであり、「MAY」[RFC2119] 。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of [RFC5234]. In addition, rules from IMAP4rev1 [RFC3501], UTF-8 [RFC3629], "Collected Extensions to IMAP4 ABNF" [RFC4466], and IMAP4 LIST Command Extensions [RFC5258] are also referenced.
正式な構文は、拡張バッカス・ナウアフォーム（ABNF）の付録B [RFC5234]で定義されたコア・ルールを含む[RFC5234]の表記法を使用します。また、IMAP4rev1の[RFC3501]、UTF-8 [RFC3629]のルールは、[RFC4466]、およびIMAP4 LISTコマンド拡張[RFC5258]も参照され、 "IMAP4 ABNFへの拡張を収集"。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。シングル「C：」場合や「S：」ラベルは複数行に適用され、その後、これらの線の間の改行は編集上明確にするためであり、実際のプロトコル交換の一部ではありません。
The "UTF8=ACCEPT" capability indicates that the server supports UTF-8 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB commands.
「UTF8 = ACCEPT」機能は、サーバがUTF8リストから文字列を、SELECTとEXAMINEする「UTF8」パラメータ、およびUTF8応答を引用し、LSUBコマンドをサポートしていることを示しています。
A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in [RFC5161]) to indicate to the server that the client accepts UTF-8 quoted-strings. The "ENABLE UTF8=ACCEPT" command MUST only be used in the authenticated state. (Note that the "UTF8=ONLY" capability described in Section 7 and the "UTF8=ALL" capability described in Section 6 imply the "UTF8=ACCEPT" capability. See additional information in these sections.)
クライアントは、クライアントがUTF8引用され、文字列を受け入れるサーバに示すために、（[RFC5161]で定義された）コマンドを「ACCEPT = UTF8を有効にする」を使用しなければなりません。 「ACCEPT = UTF8を有効にする」コマンドは、認証された状態で使用しなければなりません。 （第7節に記載された「UTF8 = ONLY」能力ことと、セクション6に記載された「UTF8 = ALL」機能は、機能を「ACCEPT = UTF8」を意味するものであります。これらのセクション内に追加情報を参照してください。）
The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit characters in atoms or quoted strings. Thus, a UTF-8 string can only be sent as a literal. This can be inconvenient from a coding standpoint, and unless the server offers IMAP4 non-synchronizing literals [RFC2088], this requires an extra round trip for each UTF-8 string sent by the client. When the IMAP server advertises the "UTF8=ACCEPT" capability, it informs the client that it supports native UTF-8 quoted-strings with the following syntax:
IMAP4rev1の[RFC3501]基本仕様は、原子または引用符で囲まれた文字列の8ビット文字を使用することを禁止します。このように、UTF-8文字列はリテラルとして送信することができます。これは、コーディングの観点から、不便なことができ、サーバはIMAP4非同期リテラル[RFC2088]を提供していますしない限り、これは、クライアントから送信された各UTF-8文字列のための余分なラウンドトリップが必要です。 IMAPサーバは「UTF8 = ACCEPT」機能をアドバタイズするとき、それは次の構文を使用して、ネイティブUTF8引用され、文字列をサポートしていることをクライアントに通知します：
string =/ utf8-quoted
文字列= / UTF8引用符で囲まれました
utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE
UTF8引用符で囲まれた= "*" DQUOTE * UQUOTED-CHAR DQUOTE
UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 ; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629
UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4。 UTF8-2、UTF8-3、およびUTF8-4は、RFC 3629で定義されている通り
When this quoting mechanism is used by the client (specifically an octet sequence beginning with *" and ending with "), then the server MUST reject octet sequences with the high bit set that fail to comply with the formal syntax in [RFC3629] with a BAD response.
この引用メカニズムは、クライアント（特にオクテットのシーケンスが*で始まる「で終わる」）で使用されている場合は、サーバーはと[RFC3629]で正式な構文に違反した高ビットがセットされたオクテットのシーケンスを拒絶しなければなりませんBAD応答。
The IMAP server MUST NOT send utf8-quoted syntax to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command.
クライアントは「UTF8をENABLE = ACCEPT」コマンドを使用して、その構文のサポートを示していない限り、IMAPサーバは、クライアントにUTF8-引用された構文を送ってはいけません。
If the server advertises the "UTF8=ACCEPT" capability, the client MAY use utf8-quoted syntax with any IMAP argument that permits a string (including astring and nstring). However, if characters outside the US-ASCII repertoire are used in an inappropriate place, the results would be the same as if other syntactically valid but semantically invalid characters were used. For example, if the client includes UTF-8 characters in the user or password arguments (and the server has not advertised "UTF8=USER"), the LOGIN command will fail as it would with any other invalid user name or password. Specific cases where UTF-8 characters are permitted or not permitted are described in the following paragraphs.
サーバは「UTF8 = ACCEPT」機能をアドバタイズした場合、クライアントは（のAStringとnstringを含む）の文字列を可能にする任意のIMAP引数を指定して、UTF8-引用された構文を使用するかもしれません。 US-ASCIIレパートリー外の文字が不適切な場所で使用されている場合は、他の構文的に有効ですが、意味的に無効な文字が使用されたかのようにしかし、結果は同じになります。クライアントは、UTF8のユーザーまたはパスワード引数の文字（およびサーバは「UTF8 = USER」を宣伝していない）が含まれている場合、それは、他の無効なユーザー名やパスワードと同じように、例えば、LOGINコマンドは失敗します。 UTF-8文字が許可または許可されていない特定の場合は、以下の段落に記載されています。
All IMAP servers that advertise the "UTF8=ACCEPT" capability SHOULD accept UTF-8 in mailbox names, and those that also support the "Mailbox International Naming Convention" described in RFC 3501, Section 5.1.3 MUST accept utf8-quoted mailbox names and convert them to the appropriate internal format. Mailbox names MUST comply with the Net-Unicode Definition (Section 2 of [RFC5198]) with the specific exception that they MUST NOT contain control characters (0000-001F, 0080-009F), delete (007F), line separator (2028), or paragraph separator (2029).
「UTF8 = ACCEPT」機能をアドバタイズすべてのIMAPサーバがメールボックス名でUTF8を受け入れ、また、RFC 3501に記載された「メールボックスの国際命名規則」をサポートするものべきで、5.1.3項では、UTF8引用符で囲まれたメールボックス名を受け入れなければならず、適切な内部フォーマットに変換します。メールボックスの名前は、彼らが制御文字（0000-001F、0080-009F）を含んではならないことを、特定の例外を除いてネットUnicodeの定義（[RFC5198]のセクション2）を遵守しなければならない、（007F）を削除し、行区切り（2028）、または段落の区切り（2029）。
An IMAP client MUST NOT issue a SEARCH command that uses a mixture of utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP server receives such a SEARCH command, it SHOULD reject the command with a BAD response (due to the conflicting charset labels).
IMAPクライアントは、UTF8引用符で囲まれた構文とUTF-8以外の検索CHARSETの混合物を使用する検索コマンドを発行してはいけません。 IMAPサーバは、そのような検索コマンドを受信した場合、それは（矛盾する文字セットのラベルによる）BAD応答でコマンドを拒否すべきです。
The "UTF8=ACCEPT" capability also indicates that the server supports the "UTF8" parameter to SELECT and EXAMINE. When a mailbox is selected with the "UTF8" parameter, it alters the behavior of all IMAP commands related to message sizes, message headers, and MIME body headers so they refer to the message with UTF-8 headers. If the mailstore is not UTF-8 header native and the SELECT or EXAMINE command with UTF-8 header modifier succeeds, then the server MUST return results as if the mailstore were UTF-8 header native with upconversion requirements as described in Section 8. The server MAY reject the SELECT or EXAMINE command with the [NOT-UTF-8] response code, unless the "UTF8=ALL" or "UTF8=ONLY" capability is advertised.
「UTF8 = ACCEPT」機能は、サーバーが選択して調べるには、「UTF8」パラメータをサポートしていることを示しています。メールボックスが「UTF8」パラメータで選択されている場合、それは彼らがUTF8ヘッダとメッセージを参照してくださいので、メッセージサイズ、メッセージのヘッダー、およびMIMEボディヘッダに関連するすべてのIMAPコマンドの動作を変更します。メールストアは、UTF-8ヘッダ天然およびEXAMINE SELECTまたはコマンドでない場合はUTF-8ヘッダモディファイアが成功すると、セクション8.に記載されるようにメールストアは、アップコンバージョン要件UTF-8ヘッダーネイティブであるかのように、サーバは、結果を返さなければなりませんサーバーは、SELECTを拒否するか、「UTF8 = ALL」または「UTF8 = ONLY」機能がアドバタイズされない限り、[NOT-UTF8]応答コードを指定して、コマンドを調べることができます。
Servers MAY include mailboxes that can only be selected or examined if the "UTF8" parameter is provided. However, such mailboxes MUST NOT be included in the output of an unextended LIST, LSUB, or equivalent command. If a client attempts to SELECT or EXAMINE such mailboxes without the "UTF8" parameter, the server MUST reject the command with a [UTF-8-ONLY] response code. As a result, such mailboxes will not be accessible by IMAP clients written prior to this specification and are discouraged unless the server advertises "UTF8=ONLY" or the server implements IMAP4 LIST Command Extensions [RFC5258].
サーバは、「UTF8」パラメータが用意されている場合にのみ選択または検査することができるメールボックスを含むかもしれません。しかしながら、そのようなメールボックスは未伸長LIST、LSUB、または同等のコマンドの出力に含まれてはいけません。クライアントは「UTF8」パラメータを指定せずに、このようなメールボックスを選択またはEXAMINEしようとすると、サーバーは、[UTF8-ONLY]応答コードを指定して、コマンドを拒絶しなければなりません。その結果、そのようなメールボックスが以前この仕様に書かれたIMAPクライアントからアクセスできなくなり、サーバーがアドバタイズ「UTF8 = ONLY」またはサーバーがIMAP4 LISTコマンド拡張[RFC5258]を実装していない限り、落胆しています。
utf8-select-param = "UTF8" ;; Conforms to <select-param> from RFC 4466
UTF8選択-のparam = "UTF8" ;; RFC 4466からの<select-param>のに準拠
C: a SELECT newmailbox (UTF8) S: ... S: a OK SELECT completed C: b FETCH 1 (SIZE ENVELOPE BODY) S: ... < UTF-8 header native results > S: b OK FETCH completed
C：SELECT newmailbox（UTF8）S ... S：OK SELECTはCを完了：B 1（SIZE ENVELOPE BODY）SをFETCH ... <UTF8ヘッダネイティブ結果> S：B OK FETCH終了
C: c EXAMINE legacymailbox (UTF8) S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access
C：NO C [NOT-UTF8]メールボックスUTF8へのアクセスをサポートしていません：legacymailbox（UTF8）Sは、EXAMINE cは
C: d SELECT funky-new-mailbox S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client
C：ファンキー-新しいメールボックスSをセレクトD：[UTF-8-ONLY]メールボックスは、UTF-8のクライアントを必要とNO dはありません
After an IMAP client successfully issues an "ENABLE UTF8=ACCEPT" command, the server MUST NOT return in LIST results any mailbox names to the client following the IMAP4 Mailbox International Naming Convention. Instead, the server MUST return any mailbox names with characters outside the US-ASCII repertoire using utf8-quoted syntax.
IMAPクライアントを正常「= UTF8をENABLE ACCEPT」コマンドを発行した後、サーバーはIMAP4メールボックスの国際命名規則次のクライアントへのLIST結果内の任意のメールボックス名を返してはなりません。代わりに、サーバーはUTF8引用符で囲まれた構文を使用してUS-ASCIIレパートリー以外の文字で任意のメールボックス名を返さなければなりません。
(The IMAP4 Mailbox International Naming Convention has proved problematic in the past, so the desire is to make this syntax obsolete as quickly as possible.)
（IMAP4メールボックスの国際命名規則は、過去に問題があることが分かっているので、願望はすぐに可能な限りこの構文は廃止することです。）
When an IMAP server advertises both the "UTF8=ACCEPT" capability and the "LIST-EXTENDED" [RFC5258] capability, the server MUST support the LIST extensions described in this section.
IMAPサーバが「UTF8 = ACCEPT」機能と「LIST拡張」[RFC5258]能力の両方をアドバタイズするとき、サーバは、このセクションで説明LIST拡張機能をサポートしなければなりません。
The "UTF8" LIST selection option tells the server to include mailboxes that only support UTF-8 headers in the output of the list command. The "UTF8ONLY" LIST selection option tells the server to include all mailboxes that support UTF-8 headers and to exclude mailboxes that don't support UTF-8 headers. Note that "UTF8ONLY" implies "UTF8", so it is not necessary for the client to request both. Use of either selection option will also result in UTF-8 mailbox names in the result as described in Section 3.3 and implies the "UTF8" List return option described in Section 3.4.2.
「UTF8」リスト選択オプションは、listコマンドの出力にUTF8ヘッダをサポートするメールボックスを含めるようにサーバーに指示します。 「UTF8ONLY」LIST選択オプションは、UTF-8のヘッダーをサポートするすべてのメールボックスを含めるようにし、UTF-8のヘッダーをサポートしていないメールボックスを除外するために、サーバーに指示します。 「UTF8ONLY」は「UTF8」を意味していますので、クライアントの両方を要求することが必要ではありません。 3.4.2項で説明した「UTF8」一覧リターンオプションを3.3節で説明するとわかるようにいずれかの選択オプションの使用は、結果でUTF8のメールボックス名になります。
If the client supplies the "UTF8" LIST return option, then the server MUST include either the "\NoUTF8" or the "\UTF8Only" mailbox attribute as appropriate. The "\NoUTF8" mailbox attribute indicates that an attempt to SELECT or EXAMINE that mailbox with the "UTF8" parameter will fail with a [NOT-UTF-8] response code. The "\UTF8Only" mailbox attribute indicates that an attempt to SELECT or EXAMINE that mailbox without the "UTF8" parameter will fail with a [UTF-8-ONLY] response code. Note that computing this information may be expensive on some server implementations, so this return option should not be used unless necessary.
クライアントは「UTF8」LISTリターンオプションを提供する場合、サーバは「\ NoUTF8」または「\ UTF8Only」適切なメールボックスの属性のいずれかを含まなければなりません。 「\ NoUTF8」メールボックス属性は、「UTF8」パラメータを使用してそのメールボックスを選択するか検討するために、試みは[NOT-UTF8]応答コードで失敗することを示しています。 「\ UTF8Only」メールボックス属性は、「UTF8」パラメータを指定せずにそのメールボックスを選択するか検討するために、試みは[UTF8-ONLY]応答コードで失敗することを示しています。必要な場合を除き、このリターン・オプションを使用すべきではありませんので、この情報を計算することは、いくつかのサーバの実装にコストがかかることに注意してください。
The ABNF [RFC5234] for these LIST extensions follows:
これらLISTの拡張のためのABNF [RFC5234]は、次のとおりです。
list-select-independent-opt =/ "UTF8"
リスト選択に依存しない-OPT = / "UTF8"
list-select-base-opt =/ "UTF8ONLY"
リスト選択ベース-OPT = / "UTF8ONLY"
mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only"
MBX-リストスキン= / "\ NoUTF8" / "\ UTF8Only"
return-option =/ "UTF8"
リターン・オプション= /「UTF8」
resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY"
RESP-テキストコード= / "NOT-UTF-8" / "UTF-8-ONLY"
If the "UTF8=APPEND" capability is advertised, then the server accepts UTF-8 headers in the APPEND command message argument. A client that sends a message with UTF-8 headers to the server MUST send them using the "UTF8" APPEND data extension. If the server also advertises the CATENATE capability (as specified in [RFC4469]), the client can use the same data extension to include such a message in a CATENATE message part. The ABNF for the APPEND data extension and CATENATE extension follows:
「UTF8 = APPEND」機能がアドバタイズされる場合、サーバーは、APPENDコマンドメッセージの引数にUTF8ヘッダを受け入れます。サーバにUTF8ヘッダを持つメッセージを送信するクライアントは、「UTF8」APPENDデータ拡張機能を使用してそれらを送らなければなりません。サーバはまた、（[RFC4469]で指定されるように）CATENATE能力をアドバタイズした場合、クライアントはCATENATEメッセージ部分にこのようなメッセージを含むように同一のデータ拡張を使用することができます。 APPENDデータの拡張子とCATENATE拡張のためのABNFは次のとおりです。
utf8-literal = "UTF8" SP "(" literal8 ")"
UTF8-リテラル= "UTF8" SP "（" literal8 "）"
append-data =/ utf8-literal
追加データ= / UTF8リテラル
cat-part =/ utf8-literal
猫パート= / UTF8リテラル
A server that advertises "UTF8=APPEND" has to comply with the requirements of the IMAP base specification and [RFC5322] for message fetching. Mechanisms for 7-bit downgrading to help comply with the standards are discussed in Downgrading mechanism for Internationalized eMail Address (IMA) [RFC5504].
「UTF8 = APPEND」をアドバタイズサーバがフェッチメッセージのIMAPベース仕様と[RFC5322]の要件を遵守しなければなりません。規格に準拠するために役立つダウングレード7ビットのためのメカニズムは、国際化メールアドレス（IMA）[RFC5504]のための機構をダウングレードに記載されています。
IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY" capability SHOULD reject an APPEND command that includes any 8-bit in the message headers with a "NO" response.
「UTF8 = APPEND」または「UTF8 = ONLY」機能をアドバタイズしていないIMAPサーバーには、「NO」と応答メッセージヘッダに任意の8ビットを含むAPPENDコマンドを拒否すべきです。
Note that the "UTF8=ONLY" capability described in Section 7 implies the "UTF8=APPEND" capability. See additional information in that section.
第7節に記載された「UTF8 = ONLY」の能力は「UTF8 = APPEND」機能を意味することに注意してください。そのセクションの追加情報を参照してください。
If the "UTF8=USER" capability is advertised, that indicates the server accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] to both arguments of the LOGIN command. The server MUST reject UTF-8 that fails to comply with the formal syntax in RFC 3629 [RFC3629] or if it encounters Unicode characters listed in Section 2.3 of SASLprep RFC 4013 [RFC4013].
「UTF8 = USER」機能が宣伝されている場合は、そのサーバがUTF8のユーザー名とパスワードを受け入れ、LOGINコマンドの両方の引数にSASLprep [RFC4013]を適用を示しています。サーバーは、UTF-8 RFCでの正式な構文3629 [RFC3629]に従わない拒絶したりしなければならない、それはSASLprep RFC 4013 [RFC4013]のセクション2.3に記載されているUnicode文字に遭遇した場合。
The "UTF8=ALL" capability indicates all server mailboxes support UTF-8 headers. Specifically, SELECT and EXAMINE with the "UTF8" parameter will never fail with a [NOT-UTF-8] response code.
「UTF8 = ALL」機能は、すべてのサーバーのメールボックスは、UTF8ヘッダをサポートして示しています。具体的には、SELECTと「UTF8」パラメータでEXAMINEは[NOT-UTF8]応答コードで失敗することはありません。
Note that the "UTF8=ONLY" capability described in Section 7 implies the "UTF8=ALL" capability. See additional information in that section.
第7節に記載された「UTF8 = ONLY」の能力は「UTF8 = ALL」の能力を意味することに注意してください。そのセクションの追加情報を参照してください。
Note that the "UTF8=ALL" capability implies the "UTF8=ACCEPT" capability.
「UTF8 = ALL」の能力は「UTF8 = ACCEPT」の能力を意味することに注意してください。
The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support the international mailbox name convention (modified UTF-7), and does not permit selection or examination of any mailbox unless the "UTF8" parameter is provided. As this is an incompatible change to IMAP, a clear warning is necessary. IMAP clients that find implementation of the "UTF8=ONLY" capability problematic are encouraged to at least detect the "UTF8=ONLY" capability and provide an informative error message to the end-user.
「UTF8 = ONLY」機能は、それが国際的なメールボックス名規則（修正UTF-7）をサポートしていませんし、「UTF8」パラメータが用意されていない限り、すべてのメールボックスの選択や検査を許可しないことを宣伝するためにIMAPサーバーを許可します。これはIMAPに互換性のない変更であるため、明確な警告が必要です。問題の「UTF8 = ONLY」機能の実装を見つけるIMAPクライアントは、少なくとも「UTF8 = ONLY」の能力を検出し、エンドユーザーに有益なエラーメッセージを提供することが奨励されます。
When an IMAP mailbox internally uses UTF-8 header native storage, the down-conversion step is necessary to permit selection or examination of the mailbox in a backwards compatible fashion will become more difficult to support. Although it is hoped that deployed IMAP servers will not advertise "UTF8=ONLY" for some years, this capability is intended to minimize the disruption when legacy support finally goes away.
IMAPメールボックスが内部UTF-8ヘッダネイティブストレージを使用する場合、ダウンコンバージョンステップがサポートすることがより困難になるであろう下位互換性の様式で選択またはメールボックスの検査を可能にするために必要です。展開されIMAPサーバは、いくつかの年のために、「UTF8 = ONLY」宣伝ではないことが期待されているが、この機能は、レガシーサポートが最終的になくなったときに混乱を最小限にするためのものです。
The "UTF8=ONLY" capability implies the "UTF8=ACCEPT" capability, the "UTF8=ALL" capability, and the "UTF8=APPEND" capability. A server that advertises "UTF8=ONLY" need not advertise the three implicit capabilities.
"UTF8 = ONLY" 機能は、 "UTF8 = ACCEPT" 機能、 "UTF8 = ALL" 機能、および "UTF8 = APPEND" 機能を意味します。 「UTF8 = ONLY」宣伝する必要はありません3つの、暗黙の機能をアドバタイズサーバー。
When an IMAP4 server uses a traditional mailbox format that includes 7-bit headers and it chooses to permit access to that mailbox with the "UTF8" parameter, it MUST support minimal up-conversion as described in this section.
IMAP4サーバは7ビットのヘッダを含む伝統的なメールボックス形式を使用して、「UTF8」パラメータを使用してそのメールボックスへのアクセスを許可することを選択した場合、このセクションに記載されているように、それが最小のアップコンバージョンをサポートしなければなりません。
The server MUST support up-conversion of the following address header-fields in the message header: From, Sender, To, CC, Bcc, Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and Reply-To. This up-conversion MUST include address local-parts in fields downgraded according to [RFC5504], address domains encoded according to Internationalizing Domain Names in Applications (IDNA) [RFC3490], and MIME header encoding [RFC2047] of display-names and any [RFC5322] comments.
サーバがサポートしなければならないアップコンバージョンメッセージヘッダ内の次のアドレスヘッダフィールドの：から、送信者に、CC、Bccの、憤慨、送信者、憤慨-TO、憤慨-CC、憤慨-BCC、憤慨-からとに返信。これは、アップコンバート[RFC5504]に記載格下げフィールド、アプリケーション（IDNA）で国際化ドメイン名[RFC3490]、およびMIMEヘッダ符号化に従って符号化されたアドレスのドメインに表示名および任意の[RFC2047]をアドレスローカル部分を含まなければなりませんRFC5322]のコメント。
The following charsets MUST be supported for up-conversion of MIME header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. If the server supports other charsets in IMAP SEARCH or IMAP CONVERT [RFC5259], it SHOULD also support those charsets in this conversion.
、UTF-8、US-ASCII、ISO-8859-1、ISO-8859-2、ISO-8859-3、ISO-8859-4：次の文字セットは、MIMEヘッダエンコーディング[RFC2047]のアップコンバージョンのためにサポートしなければなりませんISO-8859-5、ISO-8859-6、ISO-8859-7、ISO-8859-8、ISO-8859-9、ISO-8859-10、ISO-8859から14、およびISO-8859-15。サーバはIMAP検索やIMAPのCONVERT [RFC5259]で他の文字セットをサポートしている場合、それはまた、この変換では、これらの文字セットをサポートする必要があります。
Up-conversion of MIME header encoding of the following headers MUST also be implemented: Subject, Date ([RFC5322] comments only), Comments, Keywords, and Content-Description.
アップコンバージョン次のヘッダーのMIMEヘッダ符号化も実現しなければならない：件名、日付（[RFC5322]コメントのみ）、コメント、キーワード、およびコンテンツ説明。
Server implementations also SHOULD up-convert all MIME body headers [RFC2045], SHOULD up-convert or remove the deprecated (and misused) "name" parameter [RFC1341] on Content-Type, and MUST up-convert the Content-Disposition [RFC2183] "filename" parameter, except when any of these are contained within a multipart/signed MIME body part (see below). These parameters can be encoded using the standard MIME parameter encoding [RFC2231] mechanism, or via non-standard use of MIME header encoding [RFC2047] in quoted strings.
サーバ実装は、すべてのMIMEボディヘッダ[RFC2045]は非推奨（および誤用）アップコンバートまたは削除する必要があり、アップコンバート「名」パラメータSHOULDのContent-Typeの[RFC1341]、およびContent-処分[RFC2183アップ変換する必要があります「ファイル名」パラメータは、これらのいずれかがマルチパート内に含まれている場合を除き/ MIMEボディ部（下記参照）に署名しました。これらのパラメータは、または引用符で囲まれた文字列内のMIMEヘッダエンコーディング[RFC2047]の非標準の使用を介して、標準的なMIMEパラメータエンコーディング[RFC2231]メカニズムを使用して符号化することができます。
The IMAP server MUST NOT perform up-conversion of headers and content of multipart/signed, as well as Original-Recipient and Return-Path.
IMAPサーバは、アップコンバートのヘッダーと署名/マルチパートだけでなく、オリジナル・受信者のコンテンツの実行とリターンパスをしてはなりません。
When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without the "UTF8" parameter, it is the responsibility of the server to comply with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with respect to all header information transmitted over the wire. Mechanisms for 7-bit downgrading to help comply with the standards are discussed in "Downgrading Mechanism for Email Address Internationalization" [RFC5504].
IMAPサーバーは、UTF8ヘッダをサポートしており、それが「UTF8」パラメータを指定せずに、そのメールボックスの選択や検査を許可するメールボックス形式を使用する場合、IMAP4rev1の基本仕様[RFC3501]に準拠するために、サーバの責任であり、[RFC5322 】ワイヤ上を送信された全てのヘッダ情報に対する。基準を遵守を支援するためにダウングレード7ビットのメカニズム「メールアドレスの国際化のためのダウングレードメカニズム」で説明されている[RFC5504]。
An IMAP server with a mailbox that supports UTF-8 headers MUST comply with the protocol requirements implicit from Section 8. However, the code necessary for such compliance need not be part of the IMAP server itself in this case. For example, the minimal required up-conversion could be performed when a message is inserted into the IMAP-accessible mailbox.
UTF-8ヘッダーセクション8からの暗黙的なプロトコル要件を遵守しなければならないサポートメールボックスとIMAPサーバしかしながら、そのようなコンプライアンスのために必要なコードは、この場合にIMAPサーバ自体の一部である必要はありません。メッセージがIMAPアクセス可能なメールボックスの中に挿入されたときに、例えば、必要最小限のアップコンバートを行うことができました。
This adds five new capabilities ("UTF8=ACCEPT", "UTF8=USER", "UTF8=APPEND", "UTF8=ALL", and "UTF8=ONLY") to the IMAP4rev1 Capabilities registry [RFC3501].
これはIMAP4rev1の機能レジストリ[RFC3501]に（、 "UTF8 = USER"、 "UTF8 = APPEND"、 "UTF8 = ALL"、および "UTF8 = ONLY" を "UTF8 = ACCEPT"）5つの新しい機能を追加します。
This adds two new IMAP4 list selection options and one new IMAP4 list return option.
これは、2つの新しいIMAP4リスト選択オプションと一つ新しいIMAP4リスト戻りオプションを追加します。
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ：SELECTION
Implied return options(s): UTF8
暗黙のリターンオプション（S）：UTF8
LIST-EXTENDED option description: Causes the LIST response to include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter.
LIST-EXTENDEDオプションの説明：UTF8 SELECT / EXAMINEパラメータを義務付けるメールボックスを含めるようにLIST応答を引き起こします。
Published specification: RFC 5738, Section 3.4.1
公開された仕様：RFC 5738、セクション3.4.1
Security considerations: RFC 5738, Section 11
セキュリティの考慮事項：RFC 5738、第11節
Intended usage: COMMON
意図している用法：COMMON
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
Personと詳細のために連絡する電子メールアドレス：本明細書の最後に著者のアドレスを参照してください
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラ：iesg@ietf.org
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ：SELECTION
Implied return options(s): UTF8
暗黙のリターンオプション（S）：UTF8
LIST-EXTENDED option description: Causes the LIST response to include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter and exclude mailboxes that do not support the UTF8 SELECT/EXAMINE parameter.
LIST-EXTENDEDオプションの説明：パラメータを調べる/ UTF8 SELECTを強制し、パラメータを調べ/ UTF8 SELECTをサポートしていないメールボックスを除外するメールボックスを含めるようにLIST応答を引き起こします。
Published specification: RFC 5738, Section 3.4.1
公開された仕様：RFC 5738、セクション3.4.1
Security considerations: RFC 5738, Section 11
セキュリティの考慮事項：RFC 5738、第11節
Intended usage: COMMON
意図している用法：COMMON
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
Personと詳細のために連絡する電子メールアドレス：本明細書の最後に著者のアドレスを参照してください
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラ：iesg@ietf.org
LIST-EXTENDED option type: RETURN
LIST-EXTENDEDオプションタイプ：RETURN
Implied return options(s): none
暗黙のリターンオプション（S）：なし
LIST-EXTENDED option description: Causes the LIST response to include \NoUTF8 and \UTF8Only mailbox attributes.
LIST-EXTENDEDオプションの説明：\ NoUTF8と\ UTF8Onlyメールボックスの属性が含まれるようにLIST応答を引き起こします。
Published specification: RFC 5738, Section 3.4.1
公開された仕様：RFC 5738、セクション3.4.1
Security considerations: RFC 5738, Section 11
セキュリティの考慮事項：RFC 5738、第11節
Intended usage: COMMON
意図している用法：COMMON
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
Personと詳細のために連絡する電子メールアドレス：本明細書の最後に著者のアドレスを参照してください
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラ：iesg@ietf.org
The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] apply to this specification, particularly with respect to use of UTF-8 in user names and passwords. Otherwise, this is not believed to alter the security considerations of IMAP4rev1.
UTF-8 [RFC3629]とSASLprep [RFC4013]のセキュリティ問題は、特に、ユーザー名とパスワードでUTF-8の使用に関しては、本明細書に適用されます。そうでなければ、これはIMAP4rev1のセキュリティの考慮事項を変更することは考えられません。
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992.
[RFC1341] Borenstein、N.とN.フリード、「MIME（多目的インターネットメール拡張）：インターネットメッセージ本体の形式を指定し、説明するためのメカニズム」、RFC 1341、1992年6月。
[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月。
[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月。
[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月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
[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月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、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月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466]メルニコフ、A.およびC. Daboo、 "IMAP4 ABNFに収集された拡張機能"、RFC 4466、2006年4月。
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[RFC4469]レズニック、P.、 "インターネットメッセージアクセスプロトコル（IMAP）CATENATE拡張"、RFC 4469、2006年4月。
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[RFC5161] Gulbrandsenの、A.とA.メルニコフ、 "IMAPエクステンションを有効にする"、RFC 5161、2008年3月。
[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月。
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, June 2008.
[RFC5258] Leiba、B.とA.メルニコフ、 "インターネットメッセージアクセスプロトコルバージョン4 - LISTコマンドの拡張機能"、RFC 5258、2008年6月。
[RFC5259] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[RFC5259]メルニコフ、A.、およびP.コーツ、 "インターネットメッセージアクセスプロトコル - 拡張CONVERT"、RFC 5259、2008年7月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]アベル、Y.、 "国際電子メールヘッダ"、RFC 5335、2008年9月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504]藤原、K.とY.米谷、 "メールアドレスの国際化のためのメカニズムをダウングレード"、RFC 5504、2009年3月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[RFC2088]マイヤーズ、J.、 "IMAP4非同期リテラル"、RFC 2088、1997年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.
[RFC5721] Gellens、R.とC.ニューマン、 "UTF-8用のPOP3サポート"、RFC 5721、2010年2月。
Appendix A. Design Rationale
付録A.デザイン理論的根拠
This non-normative section discusses the reasons behind some of the design choices in the above specification.
この非標準のセクションは、上記の仕様で設計上の選択肢のいくつかの背後にある理由を説明します。
The basic approach of advertising the ability to access a mailbox in UTF-8 mode is intended to permit graceful upgrade, including servers that support multiple mailbox formats. In particular, it would be undesirable to force conversion of an entire server mailstore to UTF-8 headers, so being able to phase-in support for new mailboxes and gradually migrate old mailboxes is permitted by this design.
UTF-8モードでのメールボックスにアクセスする能力を広告するの基本的なアプローチは、複数のメールボックスの形式をサポートするサーバーを含め、優雅なアップグレードを可能にすることを意図しています。特に、UTF-8ヘッダにサーバ全体のメールストアの変換を強制的に望ましくないであろうので、新しいメールボックスをサポートし、同相と次第に古いメールボックスを移行することができることが、この設計によって許可されています。
"UTF8=USER" is optional because many identity systems are US-ASCII only, so it's helpful to inform the client up front that UTF-8 won't work.
多くのアイデンティティ・システムのみがUS-ASCIIであるため、「UTF8 = USER」はオプションであり、それはUTF8が動作しないことをクライアントアップフロントを通知すると便利です。
"UTF8=APPEND" is optional because it effectively requires IMAP server support for down-conversion, which is a much more complex operation than up-conversion.
それが効果的にアップコンバージョンよりもはるかに複雑な操作でダウンコンバージョンのためのIMAPサーバのサポートを必要とするため、「UTF8 = APPENDは」オプションです。
The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability problems when legacy support goes away. In the situation where backwards compatibility is broken anyway, just-send-UTF-8 IMAP has the advantage that it might work with some legacy clients. However, the difficulty of diagnosing interoperability problems caused by a just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY" capability mechanism was chosen.
レガシーサポートがなくなったときに「UTF8 = ONLY」のメカニズムは、相互運用性の問題の診断を簡素化します。後方互換性はとにかく壊れている状況では、ちょうど-送信-UTF-8 IMAPは、それはいくつかのレガシークライアントで動作する可能性があるという利点があります。しかし、ちょうど-SEND-UTF8のIMAPメカニズムに起因する相互運用性の問題を診断することの難しさは、「UTF8 = ONLY」機能のメカニズムが選ばれた理由があります。
The up-conversion requirements are designed to balance the desire to deprecate and eventually eliminate complicated encodings (like MIME header encodings) without creating a significant deployment burden for servers. As IMAP4 servers already require a MIME parser, this includes additional server up-conversion requirements not present in POP3 Support for UTF-8 [RFC5721].
アップコンバージョン要件は廃止し、最終的にサーバのための重要な展開負担を作成せずに（MIMEヘッダエンコーディングのような）複雑なエンコーディングを排除する欲望のバランスをとるように設計されています。 IMAP4サーバはすでにMIMEパーサーを必要としたように、これは、UTF-8 [RFC5721]のためのPOP3サポートに存在しない追加のサーバーのアップコンバージョン要件が含まれています。
The set of mandatory charsets comes from two sources: MIME requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. Including a requirement to up-convert widely deployed encoded ideographic charsets to UTF-8 would be reasonable for most scenarios, but may require unacceptable table sizes for some embedded devices. The open-ended recommendation to support widely deployed charsets avoids the political ramifications of attempting to list such charsets. The authors believe market forces, existing open-source software, and public conversion tables are sufficient to deploy the appropriate charsets.
MIME要件[RFC2049]と文字セットのIETF方針[RFC2277]：必須の文字セットのセットは、2つのソースから来ています。広く展開されている符号化された表意文字セットがUTF-8に変換するアップに必要含めてほとんどのシナリオのための合理的であろうが、いくつかの組み込みデバイスのために許容できないテーブル・サイズを必要とするかもしれません。広く展開されている文字セットをサポートするオープンエンドの勧告は、このような文字セットのリストを表示しようとする政治的な影響を回避することができます。著者は、市場の力、既存のオープンソースのソフトウェア、および公共の変換テーブルは、適切な文字セットを展開するのに十分であると考えています。
Appendix B. Examples Demonstrating Relationships between UTF8= Capabilities
UTF8 =機能間の関係を実証付録B.例
UTF8=ACCEPT UTF8=USER UTF8=APPEND
UTF8=ACCEPT UTF8=ALL
UTF8=ALL ; Note, same as above
UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY
UTF8=USER UTF8=ONLY ; Note, same as above
Appendix C. Acknowledgments
付録C.謝辞
The authors wish to thank the participants of the EAI working group for their contributions to this document with particular thanks to Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and Joseph Yee for their specific contributions to the discussion.
著者は、ハラルドAlvestrand、デビッド・ブラック、ランドールGellens、ARNT Gulbrandsenの、カリHurtta、ジョン・クレンシン、暁東リー、チャールズリンジー、アレクセイ・メルニコフ、サブラマニアンに特定のおかげで、この文書への貢献のためのEAIワーキンググループの参加者に感謝したいです議論への具体的な貢献のためMoonesamy、ショーン・スティール、ダニエルTaharlev、そしてジョセフ・イー。
Authors' Addresses
著者のアドレス
Pete Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
ピートレズニッククアルコム5775モアハウスドライブサンディエゴ、CA 92121から1714米
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
電話：+1 858 651 4478 Eメール：presnick@qualcomm.com URI：http://www.qualcomm.com/~presnick/
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016 US
クリス・ニューマンSun Microsystemsの800ロイヤルオークスモンロビア、カリフォルニア州91016米国
EMail: chris.newman@sun.com
メールアドレス：chris.newman@sun.com