[要約] RFC 5738は、IMAPプロトコルでUTF-8をサポートするための仕様です。目的は、国際化されたメールメッセージを効果的に処理するために、IMAPクライアントとサーバー間の文字エンコーディングの問題を解決することです。
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
UTF-8のIMAPサポート
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.
この仕様は、インターネットメッセージアクセスプロトコルバージョン4REV1（IMAP4REV1）を拡張して、UTF-8エンコードされた国際文字をユーザー名、メールアドレス、およびメッセージヘッダーでサポートします。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
この仕様は、IMAP4REV1 [RFC3501]を拡張して、「国際化されたメールヘッダー」[RFC5335]に記載されているヘッダーのUTF-8 [RFC3629]を許可します。また、UTF-8チャーセットを使用して、メールボックス名、ログイン名、およびパスワードをサポートするメカニズムも追加されます。この仕様では、5つの新しいIMAP機能を作成して、サーバーがこれらの新しい拡張機能を宣伝できるようにし、2つの新しいIMAPリスト選択オプションと新しい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].
このドキュメントの「必須」、「必要はない」、「そうでなければ」、「すべきではない」、「必要はありません」は、「要件レベルを示すためにRFCで使用するためのキーワード」で定義されていると解釈されます[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.
正式な構文では、[RFC5234]の付録Bで定義されているコアルールを含む、拡張されたバックスノーフォーム（ABNF）[RFC5234]表記を使用します。さらに、IMAP4REV1 [RFC3501]、UTF-8 [RFC3629]、「IMAP4 ABNFへの拡張を収集した」[RFC4466]、およびIMAP4リストコマンド拡張[RFC5258]からのルールも参照されています。
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」機能は、サーバーがUTF-8の引用文字列、「UTF8」パラメーターを選択および調べるパラメーター、およびLSUBコマンドからのUTF-8応答をサポートしていることを示します。
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.)
クライアントは、「Enable UTF8 = Accept」コマンド（[RFC5161]で定義）を使用して、クライアントがUTF-8の引用型のストリングを受け入れることをサーバーに示す必要があります。「UTF8 = Accept」コマンドは、認証された状態でのみ使用する必要があります。（セクション7で説明されている「UTF8 = Only」機能は、セクション6で説明されている「UTF8 = ALL」機能を意味します。「UTF8 = Accept」機能を意味します。これらのセクションの追加情報を参照してください。）
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」機能を宣伝すると、次の構文でネイティブUTF-8の引用文字弦をサポートすることをクライアントに通知します。
string =/ utf8-quoted
utf8-quoted = "*" 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
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]の正式な構文に準拠していないハイビットセットでオクテットシーケンスを拒否する必要があります。悪い反応。
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.
IMAPサーバーは、「enable utf8 = accept」コマンドを使用して、クライアントがその構文のサポートを示していない限り、クライアントに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引用構文を使用できます。ただし、米国ASCIIレパートリーの外側の文字が不適切な場所で使用されている場合、結果は他の構文的に有効であるが、意味的に無効な文字が使用されているかと同じになります。たとえば、クライアントにユーザーまたはパスワードの引数にUTF-8文字が含まれている場合（およびサーバーは「UTF8 =ユーザー」を宣伝していません）、ログインコマンドは、他の無効なユーザー名またはパスワードのように失敗します。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サーバーは、メールボックス名でUTF-8を受け入れる必要があります。また、RFC 3501に記載されている「Mailbox International Naming Convention」をサポートするものは、セクション5.1.3を受け入れる必要があります。それらを適切な内部形式に変換します。メールボックス名は、コントロール文字（0000-001F、0080-009F）、削除（007F）、ラインセパレーター（2028）を含めてはならないという特定の例外を除いて、ネットユニコード定義（[RFC5198]のセクション2）に準拠する必要があります。またはパラグラフセパレーター（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クライアントは、UTF-8以外のUTF8で引用された構文の混合物と検索charSetを使用する検索コマンドを発行してはなりません。IMAPサーバーがそのような検索コマンドを受信した場合、（競合するチャーセットラベルのため）、悪い応答でコマンドを拒否する必要があります。
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」パラメーターでメールボックスが選択されると、メッセージサイズ、メッセージヘッダー、およびMIMEボディヘッダーに関連するすべてのIMAPコマンドの動作が変更されるため、UTF-8ヘッダーのメッセージを参照します。MailStoreがUTF-8ヘッダーネイティブではなく、UTF-8ヘッダー修飾子を使用して選択または検査コマンドが成功した場合、サーバーは、セクション8で説明されているように、MailStoreがUPConversion要件を持つUTF-8ヘッダーネイティブであるかのように結果を返す必要があります。サーバーは、[utf8 = all]または「utf8 =のみ」機能が宣伝されていない限り、[not-utf-8]応答コードを使用して選択または検査コマンドを拒否できます。
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」パラメーターが提供されている場合にのみ選択または検査できるメールボックスが含まれている場合があります。ただし、そのようなメールボックスは、拡張されたリスト、LSUB、または同等のコマンドの出力に含めてはなりません。クライアントが「UTF8」パラメーターなしでそのようなメールボックスを選択または調査しようとする場合、サーバーは[UTF-8のみ]応答コードでコマンドを拒否する必要があります。その結果、このようなメールボックスは、この仕様の前に記述されたIMAPクライアントがアクセスできず、サーバーが「UTF8 =のみ」を宣伝したり、サーバーがIMAP4リストコマンド拡張機能[RFC5258]を宣伝しない限り落胆します。
utf8-select-param = "UTF8"
;; Conforms to <select-param> from RFC 4466
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: c EXAMINE legacymailbox (UTF8)
S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access
C: d SELECT funky-new-mailbox
S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client
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 = Accept」コマンドを「有効にする」コマンドを正常に発行した後、サーバーはリストに返されてはなりません。IMAP4MailboxInternational Naming Conventionに続いて、クライアントにメールボックス名をクライアントに返してはなりません。代わりに、サーバーは、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 Mailbox International Naming Conventionは過去に問題があることが証明されているため、この構文をできるだけ早く時代遅れにすることを望んでいます。）
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」機能と「リスト拡張」[RFC5258]機能の両方を宣伝する場合、サーバーはこのセクションで説明されているリスト拡張機能をサポートする必要があります。
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」リスト選択オプションは、リストコマンドの出力にUTF-8ヘッダーのみをサポートするメールボックスを含めるようにサーバーに指示します。「UTF8ONLY」リスト選択オプションは、UTF-8ヘッダーをサポートするすべてのメールボックスを含めるようにサーバーに指示し、UTF-8ヘッダーをサポートしないメールボックスを除外します。「utf8only」は「utf8」を意味するため、クライアントが両方を要求する必要はないことに注意してください。いずれかの選択オプションを使用すると、セクション3.3で説明されているように、結果にUTF-8のメールボックス名が表示され、セクション3.4.2で説明されている「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」リストリターンオプションを提供する場合、サーバーには「\ noutf8」または「\ utf8only」メールボックス属性のいずれかを必要に応じて含める必要があります。「\ noutf8」メールボックス属性は、[utf8]パラメーターを使用してそのメールボックスを選択または調べようとする試みが[not-utf-8]応答コードで失敗することを示します。「\ utf8only」メールボックス属性は、[UTF8のみ]応答コードで「UTF8」パラメーターなしでそのメールボックスを選択または調べようとする試みがそのメールボックスを選択または調べようとすることを示しています。この情報を計算することは、一部のサーバーの実装では高価になる可能性があるため、必要でない限りこの返品オプションは使用しないでください。
The ABNF [RFC5234] for these LIST extensions follows:
これらのリスト拡張機能のABNF [RFC5234]が次のとおりです。
list-select-independent-opt =/ "UTF8"
list-select-base-opt =/ "UTF8ONLY"
mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only"
return-option =/ "UTF8"
resp-text-code =/ "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コマンドメッセージ引数でUTF-8ヘッダーを受け入れます。UTF-8ヘッダーを使用してサーバーにメッセージを送信するクライアントは、「UTF8」を追加してデータ拡張機能を使用して送信する必要があります。サーバーがCatenate機能（[RFC4469]で指定されているように）も宣伝する場合、クライアントは同じデータ拡張機能を使用して、Catenateメッセージパーツにそのようなメッセージを含めることができます。追加データ拡張およびカテンテ酸エクステンションのABNFは次のとおりです。
utf8-literal = "UTF8" SP "(" literal8 ")"
utf8-literal = "utf8" sp "（" literal8 "）"
append-data =/ utf8-literal
cat-part =/ utf8-literal
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ビットを含む追加コマンドを拒否する必要があります。
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 =ユーザー」機能が宣伝されている場合、サーバーがUTF-8ユーザー名とパスワードを受け入れ、SASLPrep [RFC4013]をログインコマンドの両方の引数に適用します。サーバーは、RFC 3629 [RFC3629]の正式な構文に準拠していないUTF-8を拒否する必要があります。
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」機能は、すべてのサーバーメールボックスがUTF-8ヘッダーをサポートしていることを示しています。具体的には、[UTF8]パラメーターで[UTF8]パラメーターを選択して調べて、[NOT-UTF-8]応答コードでは決して失敗しません。
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」機能により、IMAPサーバーは、国際メールボックス名コンベンション（修正されたUTF-7）をサポートしていないことを宣伝でき、「UTF8」パラメーターが提供されない限り、メールボックスの選択または検査を許可しません。これは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.
サーバーは、メッセージヘッダーの次のアドレスヘッダーフィールドのアップコンバージョンをサポートする必要があります。に返信。このアップコンバージョンには、[RFC5504]に従って格下げされたフィールドのアドレスローカルパート、アプリケーション（IDNA）[RFC3490]の国際化ドメイン名に従ってエンコードされたアドレスドメイン、およびディスプレイ名の[RFC2047]および[任意の[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.
次の充電器は、[RFC2047]をエンコードするMIMEヘッダーのアップコンバージョンのためにサポートする必要があります：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、およびISO-8859-15。サーバーがIMAP検索で他の充電器をサポートするか、IMAP変換[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]をアップアップさせる必要があります。コンテンツタイプで非推奨（および誤用された」「名前」パラメーター[RFC1341]を削除または削除する必要があります。]「ファイル名」パラメーター。ただし、これらのいずれかがマルチパート/署名されたmimeボディパーツに含まれている場合を除きます（以下を参照）。これらのパラメーターは、[RFC2231]メカニズムをエンコードする標準MIMEパラメーターを使用して、または引用された文字列で[RFC2047]をエンコードするMIMEヘッダーの非標準使用を使用してエンコードできます。
The IMAP server MUST NOT perform up-conversion of headers and content of multipart/signed, as well as Original-Recipient and Return-Path.
IMAPサーバーは、MultiPart/署名のヘッダーとコンテンツ、およびオリジナルレシピエントおよびリターンパスのコンテンツのアップコンバージョンを実行してはなりません。
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サーバーがUTF-8ヘッダーをサポートし、「UTF8」パラメーターなしでそのメールボックスの選択または検査を許可するメールボックス形式を使用する場合、IMAP4REV1ベース仕様[RFC3501]および[RFC53222に準拠するのはサーバーの責任です。]ワイヤー上に送信されるすべてのヘッダー情報に関して。標準に準拠するのに役立つ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ヘッダーをサポートするメールボックスを備えたIMAPサーバーは、セクション8から暗黙のプロトコル要件に準拠する必要があります。ただし、このようなコンプライアンスに必要なコードは、この場合にIMAPサーバー自体の一部である必要はありません。たとえば、メッセージがIMAPアクセス可能なメールボックスに挿入されると、最小限の必要なアップコンバージョンを実行できます。
This adds five new capabilities ("UTF8=ACCEPT", "UTF8=USER", "UTF8=APPEND", "UTF8=ALL", and "UTF8=ONLY") to the IMAP4rev1 Capabilities registry [RFC3501].
これにより、5つの新しい機能（ "utf8 = accept"、 "utf8 = user"、 "utf8 = append"、 "utf8 = all"、 "utf8 = only"）がIMAP4REV1機能レジストリ[RFC3501]に追加されます。
This adds two new IMAP4 list selection options and one new IMAP4 list return option.
これにより、2つの新しいIMAP4リストの選択オプションと1つの新しいIMAP4リストの戻りオプションが追加されます。
1. LIST-EXTENDED option name: UTF8
1. リスト拡張オプション名：UTF8
LIST-EXTENDED option type: SELECTION
リスト拡張オプションタイプ：選択
Implied return options(s): UTF8
暗黙の返品オプション：UTF8
LIST-EXTENDED option description: Causes the LIST response to include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter.
リスト拡張オプション説明：リスト応答に、UTF8の選択/検査パラメーターを義務付けるメールボックスを含めます。
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
意図された使用法：共通
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
詳細については、連絡先への個人およびメールアドレス：この仕様の最後にある著者のアドレスを参照してください
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラー：iesg@ietf.org
2. LIST-EXTENDED option name: UTF8ONLY
2. リスト拡張オプション名：utf8only
LIST-EXTENDED option type: SELECTION
リスト拡張オプションタイプ：選択
Implied return options(s): UTF8
暗黙の返品オプション：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.
リスト拡張オプションの説明：リスト応答に、UTF8の選択/検査パラメーターを義務付けるメールボックスを含め、UTF8の選択/検査パラメーターをサポートしないメールボックスを除外します。
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
意図された使用法：共通
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
詳細については、連絡先への個人およびメールアドレス：この仕様の最後にある著者のアドレスを参照してください
Owner/Change controller: iesg@ietf.org
所有者/変更コントローラー：iesg@ietf.org
3. LIST-EXTENDED option name: UTF8
3. リスト拡張オプション名：UTF8
LIST-EXTENDED option type: RETURN
リスト拡張オプションタイプ：返品
Implied return options(s): none
暗黙の返品オプション：なし
LIST-EXTENDED option description: Causes the LIST response to include \NoUTF8 and \UTF8Only mailbox attributes.
リスト拡張オプション説明：リスト応答は、\ noutf8および\ utf8onlyメールボックス属性を含めます。
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
意図された使用法：共通
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
詳細については、連絡先への個人およびメールアドレス：この仕様の最後にある著者のアドレスを参照してください
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. Freed、「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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、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] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン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] Melnikov、A。およびC. Daboo、「IMAP4 ABNFへの拡張を収集した」、RFC 4466、2006年4月。
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[RFC4469] Resnick、P。、「インターネットメッセージアクセスプロトコル（IMAP）Catenate Extension」、RFC 4469、2006年4月。
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[RFC5161] Gulbrandsen、A。およびA. Melnikov、「The IMAP Enable Extension」、RFC 5161、2008年3月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、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. Melnikov、「インターネットメッセージアクセスプロトコルバージョン4 -List Command Extensions」、RFC 5258、2008年6月。
[RFC5259] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[RFC5259] Melnikov、A。およびP. Coates、「インターネットメッセージアクセスプロトコル - 拡張機能の変換」、RFC 5259、2008年7月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、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] Fujiwara、K。およびY. Youneya、「電子メールアドレス国際化の格下げメカニズム」、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[RFC2088] Myers、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. Newman、「UTF-8のPOP3サポート」、RFC 5721、2010年2月。
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.
「UTF8 =ユーザー」はオプションです。多くのIDシステムはUS-ASCIIのみであるため、UTF-8が機能しないことを前もってクライアントに通知することは役立ちます。
"UTF8=APPEND" is optional because it effectively requires IMAP server support for down-conversion, which is a much more complex operation than up-conversion.
「UTF8 = append」はオプションです。これは、ダウンコンバージョンのためにIMAPサーバーサポートを効果的に必要とするため、アップコンバージョンよりもはるかに複雑な操作です。
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」メカニズムは、レガシーサポートがなくなったときに相互運用性の問題の診断を簡素化します。とにかく後方互換性が破られる状況では、Just-Send-UTF-8 IMAPには、レガシークライアントと連携する可能性があります。ただし、Just-Send-UTF-8 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のPOP3サポートには存在しない追加のサーバーアップコンバージョン要件が含まれます[RFC5721]。
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
付録B. UTF8 =機能間の関係を示す例
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
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.
著者は、Harald Alvestrand、David Black、Randall Gellens、Arnt Gulbrandsen、Kari Hurtta、John Klensin、Xiaodong Lee、Charles Lindsey、Alexey Melnikov、Subramanianianに感謝します。Moonesamy、Shawn Steele、Daniel Taharlev、Joseph Yeeは、議論への具体的な貢献について。
Authors' Addresses
著者のアドレス
Pete Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
Pete Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121-1714 US
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016 US
クリスニューマンサンマイクロシステムズ800ロイヤルオークスモンロビア、カリフォルニア州91016米国
EMail: chris.newman@sun.com