Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 5721 QUALCOMM Incorporated
Category: Experimental C. Newman
ISSN: 2070-1721 Sun Microsystems
February 2010
POP3 Support for UTF-8
Abstract
抽象
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings.
この仕様は、ユーザー名、パスワード、メールアドレス、メッセージヘッダ、およびプロトコルレベルのテキストのエラー文字列に非エンコードされた国際文字をサポートするために、ポストオフィスプロトコルバージョン3（POP3）を拡張します。
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/rfc5721.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5721で取得することができます。
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
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 4
3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 7
3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 9
4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
This document forms part of the Email Address Internationalization (EAI) experiment described in the EAI Framework document [RFC4952] (for background, please see the charter of the EAI working group) and should be evaluated within the context of EAI. As part of the overall EAI work, email messages may be transmitted and delivered containing un-encoded UTF-8 characters, and mail drops that are accessed using POP3 [RFC1939] might natively store UTF-8.
この文書では、EAIフレームワークドキュメント[RFC4952]で説明した電子メールアドレスの国際化（EAI）実験の一部を構成する（バックグラウンドのために、EAIワーキンググループのチャーターを参照してください）とEAIのコンテキスト内で評価されるべきです。全体的なEAIワークの一部として、電子メールメッセージが送信され、未符号化されたUTF-8文字を含む送達、およびPOP3 [RFC1939]を使用してアクセスされるメール滴ネイティブUTF-8格納することがすることができます。
This specification extends POP3 [RFC1939] using the POP3 extension mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers, as described in "Internationalized Email Headers" [RFC5335]. It also adds a mechanism to support login names and passwords outside the ASCII character set, and a mechanism to support UTF-8 protocol-level error strings in a language appropriate for the user.
本明細書では、 "国際電子メールヘッダ" [RFC5335]に記載されているようにPOP3 POP3拡張メカニズム[RFC2449]を使用して、[RFC1939]は、ヘッダに未符号化されたUTF-8 [RFC3629]を可能にするように延びています。また、ASCII文字セット以外のログイン名とパスワードをサポートするためのメカニズム、およびユーザーのための適切な言語でUTF-8プロトコルレベルのエラー文字列をサポートするためのメカニズムが追加されます。
This document updates POP3 [RFC1939], and the fact that an Experimental specification updates a Standards Track specification means that people who participate in the experiment have to consider the Standard updated. In an attempt to reduce confusion, this Experimental document does not contain an "Updates" header. If and when a version of this document moves to the Standards Track, an "Updates: 1939" header should be added.
この文書では、POP3 [RFC1939]を更新し、実験的仕様が標準化過程仕様を更新しているという事実は、実験に参加し、人々が更新され、標準を考慮しなければならないことを意味します。混乱を減らすための試みでは、この実験的文書は、「更新」ヘッダーが含まれていません。このドキュメントのバージョンが標準化過程に移動したときに場合は、「更新：1939年は」ヘッダが追加されるべきです。
Within this specification, the term "down-conversion" refers to the process of modifying a message containing UTF8 headers [RFC5335] or body parts with 8bit content-transfer-encoding, as defined in MIME Section 2.8 [RFC2045], into conforming 7-bit Internet Message Format [RFC5322] with message header extensions for non-ASCII text [RFC2047] and other 7-bit encodings. Down-conversion is specified by "Downgrading Mechanism for Email Address Internationalization" [RFC5504].
7-適合に、MIMEセクション2.8 [RFC2045]で定義されるように本明細書中では、用語「ダウンコンバージョン」は、8ビットのコンテンツ転送エンコーディングでUTF8ヘッダ[RFC5335]または身体部分を含むメッセージを修正するプロセスを指し非ASCIIテキスト[RFC2047]と他の7ビットの符号化のためのメッセージヘッダ拡張子のビットインターネットメッセージフォーマット[RFC5322]。ダウン変換は、「メールアドレスの国際化のためのダウングレードメカニズム」[RFC5504]で指定されています。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります「要求レベルを示すためのRFCsにおける使用のためのキーワード」[RFC2119]に記載されているように解釈されます。
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：」ラベルは複数行に適用され、その後、これらの線の間の改行は編集上明確にするためであり、実際のプロトコル交換の一部ではありません。
Note that examples always use 7-bit ASCII characters due to limitations of this document format; in particular, some examples for the "LANG" command may appear silly as a result.
例は常に原因このドキュメントフォーマットの制限のため、7ビットのASCII文字を使用することに注意してください。具体的には、「LANG」コマンドのためのいくつかの例では、結果として愚か表示されることがあります。
Per "POP3 Extension Mechanism" [RFC2449], this document adds a new capability response tag to indicate support for a new command: LANG. The capability tag and new command are described below.
あたりの「POP3拡張メカニズム」[RFC2449]は、この文書は、新しいコマンドのサポートを示すために、新たな能力応答タグを追加します：LANG。ケーパビリティタグと新しいコマンドを以下に記載されています。
CAPA tag: LANG
CAPAタグ：LANG
Arguments with CAPA tag: none
CAPAタグ付き引数：なし
Added Commands: LANG
追加コマンド：LANG
Standard commands affected: All
標準のコマンドが影響を受ける：すべて
Announced states / possible differences: both / no
発表された状態/可能性の違い：両方/なし
Commands valid in states: AUTHENTICATION, TRANSACTION
状態で有効なコマンド：認証、TRANSACTION
Specification reference: this document
仕様参照：このドキュメント
Discussion:
討論：
POP3 allows most +OK and -ERR server responses to include human-readable text that, in some cases, might be presented to the user. But that text is limited to ASCII by the POP3 specification [RFC1939]. The LANG capability and command permit a POP3 client to negotiate which language the server should use when sending human-readable text.
POP3は、最も+ OKと-ERR、サーバーの応答は、いくつかの例では、ユーザに提示されるかもしれない、人間が読めるテキストを含めることができます。しかし、そのテキストは、POP3仕様[RFC1939]でASCIIに制限されています。 LANG機能とコマンドは、人間が読めるテキストを送信するときに、サーバーが使用すべき言語を交渉するPOP3クライアントを許可します。
A server that advertises the LANG extension MUST use the language "i-default" as described in [RFC2277] as its default language until another supported language is negotiated by the client. A server MUST include "i-default" as one of its supported languages.
[RFC2277]で説明したようにサポートされている別の言語がクライアントによって交渉されるまで、LANGの拡張子を広告サーバーはデフォルトの言語として言語「I-default」を使用しなければなりません。サーバーは、そのサポートされる言語の一つとして「I-default」を含まなければなりません。
The LANG command requests that human-readable text included in all subsequent +OK and -ERR responses be localized to a language matching the language range argument (the "Basic Language Range" as described by [RFC4647]). If the command succeeds, the server returns a +OK response followed by a single space, the exact language tag selected, another space, and the rest of the line is human-readable text in the appropriate language. This and subsequent protocol-level human-readable text is encoded in the UTF-8 charset.
人間が読めるテキストは（[RFC4647]で説明したように、「基本的な言語範囲」）OKと-ERR応答は言語範囲引数に一致する言語にローカライズされ、後続のすべて+に含まLANGコマンドを要求。コマンドが成功すると、サーバーは、単一の空白が続く+ OKレスポンスを返し、選択された正確な言語タグ、別のスペース、および行の残りの部分は、適切な言語で人間が読めるテキストです。これとその後のプロトコルレベルの人間が読めるテキストはUTF-8文字セットでエンコードされています。
If the command fails, the server returns an -ERR response and subsequent human-readable response text continues to use the language that was previously active (typically i-default).
コマンドが失敗した場合、サーバは-ERR応答を返し、その後の人間が読める応答テキストは、（一般的にI-デフォルト）以前にアクティブであった言語を使用し続けます。
The special "*" language range argument indicates a request to use a language designated as preferred by the server administrator. The preferred language MAY vary based on the currently active user.
特別な「*」言語範囲引数は、サーバ管理者によって好ましいと指定言語を使用するための要求を示します。優先言語は、現在アクティブなユーザーに基づいて異なる場合があります。
If no argument is given and the POP3 server issues a positive response, then the response given is multi-line. After the initial +OK, for each language tag the server supports, the POP3 server responds with a line for that language. This line is called a "language listing".
引数を指定しないとPOP3サーバーが肯定応答を発行されている場合、与えられた応答が複数行です。 OK初期+の後、サーバーがサポートする各言語タグのために、POP3サーバは、その言語の行で応答します。この行は、「言語のリスト」と呼ばれています。
In order to simplify parsing, all POP3 servers are required to use a certain format for language listings. A language listing consists of the language tag [RFC5646] of the message, optionally followed by a single space and a human-readable description of the language in the language itself, using the UTF-8 charset.
構文解析を簡素化するために、すべてのPOP3サーバは、言語リストのための特定の形式を使用する必要があります。言語のリストは、UTF-8文字セットを使用して、必要に応じて、単一空間と言語自体に言語の人間可読の記述に続いてメッセージの言語タグ[RFC5646]から成ります。
Examples:
例：
< Note that some examples do not include the correct character accents due to limitations of this document format. >
<いくつかの例には、この文書フォーマットの制限のために正しい文字のアクセントが含まれていないことに注意してください。 >
< The server defaults to using English i-default responses until the client explicitly changes the language. >
<クライアントが明示的に言語を変更するまで英語I-デフォルトの応答を使用するサーバーのデフォルト。 >
C: USER karen S: +OK Hello, karen C: PASS password S: +OK karen's maildrop contains 2 messages (320 octets)
C：USERカレンS：+ OKこんにちは、カレンC：PASSパスワードS：+ OKカレンのメールドロップが2つのメッセージ（320オクテット）が含まれてい
< Client requests deprecated MUL language. Server replies with -ERR response. >
<クライアントの要求は、MUL言語を非推奨します。サーバーは-ERR応答で応答します。 >
C: LANG MUL S: -ERR invalid language MUL
C：LANG MUL S：-ERR無効な言語MUL
< A LANG command with no parameters is a request for a language listing. >
<パラメータなしでLANGコマンドは、言語のリストの要求です。 >
C: LANG S: +OK Language listing follows: S: en English S: en-boont English Boontling dialect S: de Deutsch S: it Italiano S: es Espanol S: sv Svenska S: i-default Default language S: .
C：LANG S：+ OK言語のリストは、次のとおりです。S：EN英語S：エンboont英語Boontling方言のS：デドイツS：それはイタリア語S：ES EspanolでS：SVスヴェンスカS：I-デフォルトデフォルト言語S：。
< A request for a language listing might fail. >
<言語のリストの要求が失敗することがあります。 >
C: LANG S: -ERR Server is unable to list languages
C：LANG S：-ERRサーバーは、言語の一覧を表示することができません
< Once the client changes the language, all responses will be in that language, starting with the response to the LANG command. >
クライアントは、言語を変更したら、<、すべての応答は、LANGコマンドに応答して始まる、その言語になります。 >
C: LANG es S: +OK es Idioma cambiado
C：LANGはSです：言語に変更されて+ OK
< If a server does not support the requested primary language, responses will continue to be returned in the current language the server is using. >
サーバは要求された第一言語をサポートしていない場合は、<、応答は、サーバが使用している現在の言語で返されていきます。 >
C: LANG uga S: -ERR es Idioma <<UGA>> no es conocido
C：UGA LANG S：ERRはUGAである>> <<言語知られていません
C: LANG sv S: +OK sv Kommandot "LANG" lyckades
C：S専用LANG：+ OKコマンドエン "LANG" 成功しました
C: LANG * S: +OK es Idioma cambiado
C：LANG * S：+ OKが変更された言語
Per "POP3 Extension Mechanism" [RFC2449], this document adds a new capability response tag to indicate support for new server functionality, including a new command: UTF8. The capability tag and new command and functionality are described below.
UTF8：あたりの「POP3拡張メカニズム」[RFC2449]は、この文書は、新しいサーバーの新しいコマンドを含む機能のサポートを示すために、新たな能力応答タグを追加します。ケーパビリティタグと新しいコマンドと機能を以下に記載されています。
CAPA tag: UTF8
CAPAタグ：UTF8
Arguments with CAPA tag: USER
CAPAタグ付き引数：USER
Added Commands: UTF8
追加コマンド：UTF8
Standard commands affected: USER, PASS, APOP, LIST, TOP, RETR
影響を受けた標準コマンド：USER、PASS、APOP、LIST、TOP、RETR
Announced states / possible differences: both / no
発表された状態/可能性の違い：両方/なし
Commands valid in states: AUTHORIZATION
状態で有効なコマンド：AUTHORIZATIONを
Specification reference: this document
仕様参照：このドキュメント
Discussion:
討論：
This capability adds the "UTF8" command to POP3. The UTF8 command switches the session from ASCII to UTF-8 mode.
この機能は、POP3に「UTF8」コマンドを追加します。 UTF8コマンドは、ASCIIからUTF8モードにセッションを切り替えます。
The UTF8 command enables UTF-8 mode. The UTF8 command has no parameters.
UTF8コマンドは、UTF8モードを有効にします。 UTF8コマンドにはパラメータはありません。
Maildrops can natively store UTF-8 or be limited to ASCII. UTF-8 mode has no effect on messages in an ASCII-only maildrop. Messages in native UTF-8 maildrops can be ASCII or UTF-8 using internationalized headers [RFC5335] and/or 8bit content-transfer-encoding, as defined in MIME Section 2.8 [RFC2045]. In UTF-8 mode, both UTF-8 and ASCII messages are sent to the client as-is (without conversion). When not in UTF-8 mode, UTF-8 messages in a native UTF-8 maildrop MUST be down-converted (downgraded) to comply with unextended POP and Internet Mail Format. POP servers (unlike SMTP and Submit servers) are not required to use "Downgrading Mechanism for Email Address Internationalization" [RFC5504].
MaildropsはネイティブにUTF-8を格納することができますかASCIIに制限されます。 UTF-8モードでは、ASCIIのみのメールドロップでメッセージには影響しません。 MIMEセクション2.8 [RFC2045]で定義されるように、天然のUTF-8 maildrops内のメッセージは、国際ヘッダ[RFC5335]及び/又は8ビットのコンテンツ転送エンコードを使用して、ASCIIまたはUTF-8であることができます。 UTF-8モードでは、両方のUTF-8およびASCIIのメッセージが（変換なし） - であるとしてクライアントに送信されます。ダウンコンバートされない時はUTF-8モードでは、UTF-8のメッセージネイティブUTF-8メールドロップでなければなりません伸長していないPOPとインターネットメール形式に準拠する（ダウングレード）。 POPサーバ（SMTPとは異なり、およびサーバを提出）は、「メールアドレスの国際化のためのメカニズムをダウングレード」を使用する必要はありません[RFC5504]。
Discussion: The main argument against a single required mechanism for downgrading by a POP server is that the only clients that have any use for a standardized downgraded message (because they wish to interpret downgrade headers, for example) are ones that can support UTF-8 and, hence, will issue the UTF8 command in the first place. The counter argument to this is that clients that do not support UTF-8 might be upgraded in the future; it's desirable for an upgraded client to be capable of interpreting prior downgraded messages in the local mail store, which is most likely if the messages were downgraded using one standardized procedure.
ディスカッション：POPサーバーでダウングレードするための単一の必要なメカニズムに対する主な引数は、（彼らはダウングレードヘッダを解釈したいので、たとえば、）標準化されたダウングレードメッセージのための任意の使用を持っているだけで、クライアントがUTF-8をサポートできるものであることですそして、それゆえ、最初の場所でUTF8コマンドを発行します。これに対する反論は、UTF-8をサポートしないクライアントは、将来的にアップグレードされるかもしれないということです。アップグレードされたクライアントは、前のメッセージを1つの標準化された手順を使用して格下げされた場合は、最も可能性が高いローカルメールストアにメッセージを格下げ解釈することができるようすることが望ましいです。
Therefore, while POP servers are not required to use "Downgrading Mechanism for Email Address Internationalization" [RFC5504], there are advantages to them doing so.
したがって、[RFC5504] POPサーバは、「メールアドレスの国際化のためのメカニズムをダウングレード」を使用する必要はありませんが、そうするそれらの利点があります。
Note that even in UTF-8 mode, MIME binary content-transfer-encoding is still not permitted.
UTF-8モードでは、MIMEバイナリコンテンツ転送符号化がまだ許可されていないことに留意されたいです。
The octet count (size) of a message reported in a response to the LIST command SHOULD match the actual number of octets sent in a RETR response (not counting byte-stuffing). Sizes reported elsewhere, such as in STAT responses and non-standardized, free-form text in positive status indicators (following "+OK") need not be accurate, but it is preferable if they are.
RETR応答で送信されたオクテットの実際の数と一致する必要がLISTコマンドに応答して報告されたメッセージのオクテット数（サイズ）（バイトスタッフィングをカウントしません）。そのような正のステータスインジケータでSTAT応答および非標準化、自由形式のテキストのように他の場所で報告されたサイズは、正確である必要はありません（「+ OK」以下）が、彼らがある場合に好適です。
Discussion: Mail stores are either ASCII or native UTF-8, and clients either issue the UTF8 command or not. The message needs converting only when it is native UTF-8 and the client has not issued the UTF-8 command, in which case the server must down-convert it. The down-converted message may be larger. The server may choose various strategies regarding down-conversion, which include when to down-convert, whether to cache or store the down-converted form of a message (and if so, for how long), and whether to calculate or retain the size of a down-converted message independently of the down-converted content. If the server does not have immediate access to the accurate down-converted size, it may be faster to estimate rather than calculate it. Servers are expected to normally follow the RFC 1939 [RFC1939] text on using the "exact size" in a scan listing, but there may be situations with maildrops containing very large numbers of messages in which this might be a problem. If the server does estimate, reporting a scan listing size smaller than what it turns out to be could be a problem for some clients. In summary, it is better for servers to report accurate sizes, but if this is not possible, high guesses are better than small ones. Some POP servers include the message size in the non-standardized text response following "+OK" (the 'text' production of RFC 2449 [RFC2449]), in a RETR or TOP response (possibly because some examples in POP3 [RFC1939] do so). There has been at least one known case of a client relying on this to know when it had received all of the message rather than following the POP3 [RFC1939] rule of looking for a line consisting of a termination octet (".") and a CRLF pair. While any such client is non-compliant, if a server does include the size in such text, it is better if it is accurate.
ディスカッション：メールストアは、ASCIIまたはネイティブUTF8、およびクライアントUTF8コマンドを発行するかどうかのどちらかのどちらかです。メッセージは、それがネイティブのUTF-8で、クライアントは、サーバがそれをダウン変換する必要があり、その場合にはUTF-8のコマンドを発行していないときにのみ変換する必要があります。ダウンコンバートされたメッセージは、大きくてもよいです。サーバがダウンコンバートに、（もしそうなら、どのくらいのための）メッセージのダウン変換されたフォームをキャッシュまたは格納するかどうか、およびサイズを計算するか、保持するかどうかを含むダウンコンバージョンに関する様々な戦略を選択することができますダウンコンバートされたメッセージの独立にダウンコンバートコンテンツの。サーバが正確なダウンコンバートされたサイズへの即時アクセスを持っていない場合は、推定ではなく、それを計算するのに速いかもしれません。サーバは、通常のスキャンリストに「正確なサイズを」使用上のRFC 1939 [RFC1939]のテキストに従うことが期待されているが、これは問題になる可能性のあるメッセージの非常に大きな数字を含むmaildropsと状況があるかもしれません。サーバが推定しなければ、それはいくつかのクライアントの問題である可能性があることが判明したものよりも小さいスキャンリストのサイズを報告します。要約すると、それは正確なサイズを報告するサーバのためのより良いですが、これが不可能な場合は、高い推測が小さなものよりも優れています。一部のPOPサーバーでは、「+ OK」以下の非標準化されたテキスト応答でメッセージのサイズを含める（の「テキスト」の生産RFC 2449 [RFC2449]）、RETRまたはTOP応答（POP3 [RFC1939]でいくつかの例が行う可能性があるためでそう）。 （「」）、それはメッセージのすべてを受け取っていた時に知ってこれに頼るのではなく、終端オクテットからなるラインを探しているのPOP3 [RFC1939]の規則次のクライアントの少なくとも1つの既知場合があったとA CRLFペア。サーバは、テキストでのサイズが含まれない場合、そのようなクライアントは、非対応ですが、正確であれば良いです。
Clients MUST NOT issue the STLS command [RFC2595] after issuing UTF8; servers MAY (but are not required to) enforce this by rejecting with an "-ERR" response an STLS command issued subsequent to a successful
クライアントは、UTF8を発行した後STLSコマンド[RFC2595]を発行してはなりません。サーバーは、MAY（ただし、する必要はありません）STLSコマンドが成功した後に発行される「-ERR」応答で拒否することによって、これを施行
UTF8 command. (Because this is a protocol error as opposed to a failure based on conditions, an extended response code [RFC2449] is not specified.)
UTF8コマンド。 （これは、プロトコル・エラーであるため、指定されていない条件に基づいて故障、拡張応答コード[RFC2449]とは対照的に）。
If the USER argument is included with this capability, it indicates that the server accepts UTF-8 user names and passwords.
USER引数がこの機能に含まれている場合は、サーバーがUTF-8のユーザー名とパスワードを受け入れることを示しています。
Servers that include the USER argument in the UTF8 capability response SHOULD apply SASLprep [RFC4013] to the arguments of the USER and PASS commands.
UTF8能力応答でUSER引数を含めるサーバはUSERとPASSコマンドの引数にSASLprep [RFC4013]を適用すべきです。
A client or server that supports APOP and permits UTF-8 in user names or passwords MUST apply SASLprep [RFC4013] to the user name and password used to compute the APOP digest.
APOPをサポートし、ユーザー名やパスワードにUTF-8を許可するクライアントまたはサーバがAPOPダイジェストを計算するために使用されるユーザー名とパスワードにSASLprep [RFC4013]を適用しなければなりません。
When applying SASLprep [RFC4013], servers MUST reject UTF-8 user names or passwords that contain a Unicode character listed in Section 2.3 of SASLprep [RFC4013]. When applying SASLprep to the USER argument, the PASS argument, or the APOP username argument, a compliant server or client MUST treat them as a query string (i.e., unassigned Unicode codepoints are allowed). When applying SASLprep to the APOP password argument, a compliant server or client MUST treat them as a stored string (i.e., unassigned Unicode codepoints are prohibited).
SASLprep [RFC4013]を適用すると、サーバはSASLprep [RFC4013]のセクション2.3に記載されているUnicode文字が含まれているUTF-8のユーザー名やパスワードを拒絶しなければなりません。 USER引数、PASS引数、またはAPOPのusername引数にSASLprepを適用する場合、準拠のサーバーまたはクライアントが（すなわち、未割り当てのUnicodeコードポイントが許可されている）、クエリ文字列としてそれらを扱わなければなりません。 APOPパスワード引数にSASLprepを適用する場合、準拠したサーバーまたはクライアントが格納されている文字列として扱う必要があります（つまり、割り当てられていないUnicodeのコードポイントは禁止されています）。
The client does not need to issue the UTF8 command prior to using UTF-8 in authentication. However, clients MUST NOT use UTF-8 in USER, PASS, or APOP commands unless the USER argument is included in the UTF8 capability response.
クライアントは、認証にUTF8を使用する前にUTF8コマンドを発行する必要はありません。ただし、クライアントは、PASS、USERでUTF8を使用してはならない、またはUSERの引数がUTF8能力応答に含まれていない限り、APOPコマンド。
The server MUST reject UTF-8 user names or passwords that fail to comply with the formal syntax in UTF-8 [RFC3629].
サーバーはUTF-8での正式な構文[RFC3629]に違反したUTF-8のユーザー名やパスワードを拒絶しなければなりません。
Use of UTF-8 in the AUTH command is governed by the POP3 SASL [RFC5034] mechanism.
AUTHコマンドでUTF-8の使用は、POP3 SASL [RFC5034]メカニズムによって支配されています。
When a POP3 server uses a native UTF-8 maildrop, it is the responsibility of the server to comply with the POP3 base specification [RFC1939] and Internet Message Format [RFC5322] when not in UTF-8 mode. Mechanisms for 7-bit downgrading to help comply with the standards are described in "Downgrading Mechanism for Email Address Internationalization" [RFC5504].
POP3サーバーがネイティブUTF-8メールドロップを使用するときは、サーバーの責任がないときは、UTF-8モードでPOP3の基本仕様[RFC1939]インターネットメッセージ形式[RFC5322]に準拠することです。基準を遵守を支援するためにダウングレード7ビットのためのメカニズムは、「メールアドレスの国際化のためのダウングレードメカニズム」[RFC5504]で説明されています。
This specification adds two new capabilities ("UTF8" and "LANG") to the POP3 capability registry [RFC2449].
この仕様は、POP3機能レジストリ[RFC2449]への2つの新しい機能（「UTF8」と「LANG」）を追加します。
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.
UTF-8 [RFC3629]とSASLprep [RFC4013]のセキュリティ問題は、特に、ユーザー名とパスワードでUTF-8の使用に関しては、本明細書に適用されます。
The "LANG *" command might reveal the existence and preferred language of a user to an active attacker probing the system if the active language changes in response to the USER, PASS, or APOP commands prior to validating the user's credentials. Servers MUST implement a configuration to prevent this exposure.
「LANG *」コマンドは、ユーザー操作に応答してアクティブな言語が変更された場合、システムをアクティブプロービング攻撃者に存在し、ユーザの好みの言語を明らかにするPASS、またはAPOPには、ユーザーの資格情報を検証する前にコマンドがあります。サーバーは、この暴露を防止するための構成を実装しなければなりません。
It is possible for a man-in-the-middle attacker to insert a LANG command in the command stream, thus making protocol-level diagnostic responses unintelligible to the user. A mechanism to integrity-protect the session, such as Transport Layer Security (TLS) [RFC2595] can be used to defeat such attacks.
したがって、ユーザに理解できないプロトコルレベルの診断応答を行う、コマンドストリームにLANGコマンドを挿入するためのman-in-the-middle攻撃が可能です。そのようなトランスポート層セキュリティ（TLS）[RFC2595]として、セッションを整合性保護のメカニズムは、このような攻撃を打ち負かすために使用することができます。
Modifying server authentication code (in this case, to support UTF-8) needs to be done with care to avoid introducing vulnerabilities (for example, in string parsing).
（UTF-8をサポートするために、このケースでは）サーバ認証コードを変更する（例えば、文字列解析中）の脆弱性を導入することを避けるために注意して行う必要があります。
The UTF8 command description (Section 3.1) contains a discussion on reporting inaccurate sizes. An additional risk to doing so is that, if a client allocates buffers based on the reported size, it may overrun the buffer, crash, or have other problems if the message data is larger than reported.
UTF8コマンドの説明（3.1節）は、不正確なサイズを報告に関する議論が含まれています。そうすることへの追加的なリスクは、クライアントが報告されたサイズに基づいてバッファを割り当てた場合、それはバッファ、クラッシュをオーバーランしたり、メッセージデータが報告されたよりも大きい場合、他の問題を抱えている、ということです。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[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月。
[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月。
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[RFC2449] Gellens、R.、ニューマン、C.、およびL. Lundblade、 "POP3拡張メカニズム"、RFC 2449、1998年11月。
[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月。
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]フィリップス、A.とM.デイヴィス、 "言語タグのマッチング"、BCP 47、RFC 4647、2006年9月。
[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月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]ニューマン、C.、 "IMAP、POP3およびACAPとTLSを使用する"、RFC 2595、1999年6月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism", RFC 5034, July 2007.
[RFC5034] Siemborski、R.とA.メノンセン、 "ポストオフィスプロトコル（POP3）簡易認証セキュリティー層（SASL）認証メカニズム"、RFC 5034、2007年7月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504]藤原、K.とY.米谷、 "メールアドレスの国際化のためのメカニズムをダウングレード"、RFC 5504、2009年3月。
Appendix A. Design Rationale
付録A.デザイン理論的根拠
This non-normative section discusses the reasons behind some of the design choices in the above specification.
この非標準のセクションは、上記の仕様で設計上の選択肢のいくつかの背後にある理由を説明します。
Having servers perform up-conversion so that, at a minimum, RFC2047- encoded words are decoded into UTF-8 is tempting, since this is an area that clients often fail to correctly implement. However, after much discussion, the EAI group felt that the benefits did not justify the burden.
これは、クライアントが頻繁に正しく実装に失敗した領域であるので、最低でも、RFC2047-エンコードされた単語がUTF-8にデコードされている、ように、サーバがアップコンバージョンを実行持つことは、魅力的です。しかし、多くの議論の後、EAI・グループは、利益が負担を正当化しなかったことを感じました。
Due to interoperability problems with RFC 2047 and limited deployment of RFC 2231, it is hoped these 7-bit encoding mechanisms can be deprecated in the future when UTF-8 header support becomes prevalent.
原因RFC 2047及びRFC 2231の制限された配備との相互運用性の問題のために、UTF-8ヘッダサポートが優勢になった場合、これらの7ビットの符号化機構は、将来的に廃止されることができる期待されています。
USER is optional because the implementation burden of SASLprep [RFC4013] is not well understood, and mandating such support in all cases could negatively impact deployment.
SASLprep [RFC4013]の実装の負担を十分に理解されておらず、全ての場合において、このようなサポートを義務付けることは、負の展開に影響を与える可能性があるので、ユーザは任意です。
While it is possible to provide useful examples for language negotiation without support for non-ASCII characters, it is difficult to provide useful examples for commands specifically designed to use the UTF-8 charset un-encoded when the document format is limited to ASCII. As a result, there are no plans to provide examples for that part of the specification as long as this remains an experimental proposal. However, implementers of this specification are encouraged to provide examples to the document authors for a future revision.
それは非ASCII文字のサポートなしで、言語ネゴシエーションのための有用な例を提供することが可能であるが、特に、文書形式がASCIIに限定されている場合にUTF-8文字セット未エンコードを使用するように設計されたコマンドの有用な例を提供することは困難です。その結果、限り、これは実験的な提案のままとして、仕様の一部のための例を提供する予定はありません。しかし、この仕様の実装は、今後の改訂のための文書の作者に例を提供することが奨励されています。
While down-conversion of native UTF-8 messages is mandatory in the absence of the UTF8 command, servers are not required to use "Downgrading Mechanism for Email Address Internationalization" [RFC5504] to do so. As clients are upgraded with UTF-8 support and the ability to intelligently handle (e.g., display and reply to) UTF-8 messages that were downgraded in transit, it is better if they are also able to handle messages in the local mail store that were downgraded by the POP server. This is more likely if the POP server downgrades messages using the same mechanism as an SMTP server.
ネイティブUTF8メッセージのダウンコンバージョンがUTF8コマンドが存在しない場合には必須ですが、サーバがそうするように、「メールアドレスの国際化のためのダウングレードメカニズム」[RFC5504]を使用する必要はありません。クライアントはUTF-8をサポートし、輸送中に格下げされたインテリジェントUTF-8のメッセージを（例えば、ディスプレイをしてに返信）を処理する能力をアップグレードしているとして、彼らはまた、ローカルメールストアにメッセージを処理することができれば、それが優れていることPOPサーバーによって格下げされました。 POPサーバーがSMTPサーバと同じメカニズムを使用してメッセージをダウングレードする場合、これは可能性が高いです。
Appendix B. Acknowledgments
付録B.謝辞
Thanks to John Klensin, Tony Hansen, and other EAI working group participants who provided helpful suggestions and interesting debate that improved this specification.
ジョン・クレンシン、トニーハンセン、および有益な提案や、この仕様を向上し、興味深い議論を提供する他のEAIワーキンググループ参加者に感謝します。
Authors' Addresses
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92651 US
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92651米国
EMail: rg+ietf@qualcomm.com
メールアドレス：rg+ietf@qualcomm.com
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016-6347 US
クリス・ニューマンSun Microsystemsの800ロイヤルオークスモンロビア、カリフォルニア州91016から6347米
EMail: chis.newman@sun.com
メールアドレス：chis.newman@sun.com