[要約] RFC 5721は、POP3プロトコルでUTF-8をサポートするための仕様です。目的は、国際化されたメールメッセージを効果的に処理するために、POP3クライアントとサーバー間でUTF-8エンコーディングを使用することです。
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
UTF-8のPOP3サポート
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（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/rfc5721.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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
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ワーキンググループの憲章を参照してください）で説明されている電子メールアドレスInternationalization（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]に記載されているように、HeadersでエンコードされていないUTF-8 [RFC3629]をヘッダー内のPOP3拡張メカニズム[RFC2449]を使用してPOP3 [RFC1939]を拡張します。また、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].
この仕様内で、「ダウンコンバージョン」という用語は、MIMEセクション2.8 [RFC2045]で定義されているように、UTF8ヘッダー[RFC5335]または8ビットのコンテンツ転移エンコードを含むボディ部分を含むメッセージを変更するプロセスを指します。非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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、「要件レベルを示すためにRFCで使用するためのキーワード」で説明されているように解釈される[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タグ：ラング
Arguments with CAPA tag: none
CAPAタグとの引数：なし
Added Commands: LANG
コマンドを追加：Lang
Standard commands affected: All
影響を受ける標準コマンド：すべて
Announced states / possible differences: both / no
発表された州 /可能な違い：両方 / no
Commands valid in states: AUTHENTICATION, 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.
Lang拡張機能を宣伝するサーバーは、[RFC2277]に記載されている言語「I-Default」をデフォルト言語として使用する必要があります。サーバーには、サポートされている言語の1つとして「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.
Langコマンドは、後続のすべてのOKおよび-ERR応答に含まれる人間の読み取り可能なテキストを、言語範囲引数（[RFC4647]で説明する「基本言語範囲」）に一致する言語にローカライズすることを要求します。コマンドが成功した場合、サーバーは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-Default）を使用し続けます。
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サーバーが言語リストに特定の形式を使用する必要があります。言語リストは、メッセージの言語タグ[RFC5646]で構成されており、オプションでは、UTF-8チャーセットを使用して、言語自体の言語の単一のスペースと人間の読み取り可能な説明が続きます。
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-default応答を使用することにデフォルトです。>
C: USER karen
S: +OK Hello, karen
C: PASS password
S: +OK karen's maildrop contains 2 messages (320 octets)
< Client requests deprecated MUL language. Server replies with -ERR response. >
<クライアントは非推奨のMUL言語を要求します。サーバーは-err応答で返信します。>
C: LANG MUL
S: -ERR invalid language MUL
< A LANG command with no parameters is a request for
a language listing. >
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: .
< A request for a language listing might fail. >
<言語リストのリクエストは失敗する可能性があります。>
C: LANG
S: -ERR Server is unable to list languages
< 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
< 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: LANG sv
S: +OK sv Kommandot "LANG" lyckades
C: LANG *
S: +OK es Idioma cambiado
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.
「POP3拡張メカニズム」[RFC2449]によると、このドキュメントは、新しいコマンド：UTF8を含む新しいサーバー機能のサポートを示す新しい機能応答タグを追加します。機能タグと新しいコマンドと機能については、以下に説明します。
CAPA tag: UTF8
CAPAタグ：UTF8
Arguments with CAPA tag: USER
CAPAタグとの引数：ユーザー
Added Commands: UTF8
コマンドの追加：UTF8
Standard commands affected: USER, PASS, APOP, LIST, TOP, RETR
影響を受ける標準コマンド：ユーザー、パス、apop、リスト、トップ、ret
Announced states / possible differences: both / no
発表された州 /可能な違い：両方 / no
Commands valid in states: 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.
この機能は、「UTF8」コマンドをPOP3に追加します。UTF8コマンドは、ASCIIからUTF-8モードにセッションを切り替えます。
The UTF8 command enables UTF-8 mode. The UTF8 command has no parameters.
UTF8コマンドはUTF-8モードを有効にします。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-Only Maildropのメッセージに影響を与えません。ネイティブUTF-8メールドロップのメッセージは、MIMEセクション2.8 [RFC2045]で定義されているように、国際化ヘッダー[RFC5335]および/または8ビットのコンテンツ転移エンコードを使用してASCIIまたはUTF-8にすることができます。UTF-8モードでは、UTF-8メッセージとASCIIメッセージの両方がクライアントに送信されます（変換なし）。UTF-8モードでない場合、ネイティブUTF-8メールドロップのUTF-8メッセージは、拡張されたポップおよびインターネットメール形式に準拠するためにダウンコンバージョン（ダウングレード）する必要があります。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.
ディスカッション：ポップサーバーによる格下げに必要な単一の必要なメカニズムに対する主な引数は、標準化された格下げメッセージに使用する唯一のクライアントが（たとえば、ダウングレードヘッダーを解釈したいため）、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]を使用する必要はありませんが、そうすることには利点があります。
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.
リストコマンドへの応答で報告されたメッセージのオクテットカウント（サイズ）は、RET応答で送信された実際のオクテット数（バイトストーフをカウントしない）と一致する必要があります。統計応答や標準化されていない自由形式のテキスト（「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またはネイティブUTF-8のいずれかであり、クライアントはUTF8コマンドを発行するかどうかのいずれかです。メッセージは、ネイティブのUTF-8であり、クライアントがUTF-8コマンドを発行していない場合にのみ変換する必要があります。その場合、サーバーはダウンコンバートする必要があります。変換されたメッセージが大きくなる可能性があります。サーバーは、ダウンコンバージの時期、ダウンコンバージョンフォームのメッセージのキャッシュまたは保存（およびその場合、どのくらい）を保存するか、サイズを計算または保持するかどうかを含む、ダウンコンバージョンに関するさまざまな戦略を選択できます。ダウンコンテンツのコンテンツとは独立して、ダウンコンバージされたメッセージの。サーバーが正確なダウンコンバージョンサイズにすぐにアクセスできない場合、計算するのではなく推定する方が速い場合があります。サーバーは通常、スキャンリストで「正確なサイズ」を使用するRFC 1939 [RFC1939]テキストに従うことが期待されますが、これが問題になる可能性のある非常に多数のメッセージを含むメールドロップの状況がある場合があります。サーバーが推定している場合、スキャンリストサイズを報告している場合は、一部のクライアントにとって問題が問題になる可能性があります。要約すると、サーバーが正確なサイズを報告する方が良いですが、これが不可能な場合、高い推測は小さなものよりも優れています。一部のポップサーバーには、「OK」後の非標準化されたテキスト応答（RFC 2449 [RFC2449]の「テキスト」制作）に続くメッセージサイズが含まれています（おそらくPOP3 [RFC1939]の例があるため、おそらくそうです。）。クライアントがこれに依存しているという少なくとも1つの既知のケースがあり、POP3 [RFC1939]のルールに従うのではなく、すべてのメッセージを受け取ったことを知ることができました。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 command. (Because this is a protocol error as opposed to a failure based on conditions, an extended response code [RFC2449] is not specified.)
クライアントは、UTF8を発行した後、STLSコマンド[RFC2595]を発行してはなりません。サーバーは、成功したUTF8コマンドの後に発行されたSTLSコマンドを「-err」応答で拒否することにより、これを実施することができます（ただし必要ありません）。（これは条件に基づく障害とは対照的にプロトコルエラーであるため、拡張応答コード[RFC2449]は指定されていません。）
If the USER argument is included with this capability, it indicates that the server accepts UTF-8 user names and passwords.
ユーザーの引数がこの機能に含まれている場合、サーバーが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機能応答のユーザー引数を含むサーバーは、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にリストされているユニコード文字を含むUTF-8ユーザー名またはパスワードを拒否する必要があります。SASLPrepをユーザー引数、Pass引数、またはAPOPユーザー名引数に適用する場合、準拠したサーバーまたはクライアントはそれらをクエリ文字列として扱う必要があります（つまり、未割り当てのUnicode CodePointsは許可されます）。SASLPrepをAPOPパスワード引数に適用する場合、準拠したサーバーまたはクライアントは、それらを保存された文字列として扱う必要があります（つまり、未割り当てのUnicode CodePointsは禁止されています）。
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.
クライアントは、認証でUTF-8を使用する前に、UTF8コマンドを発行する必要はありません。ただし、ユーザーの引数がUTF8機能応答に含まれていない限り、クライアントはユーザー、パス、またはAPOPコマンドでUTF-8を使用してはなりません。
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.
認証コマンドでの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 *」コマンドは、ユーザーの資格情報を検証する前にユーザー、パス、または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コマンドを挿入することができ、したがって、プロトコルレベルの診断応答をユーザーに理解できないようにすることができます。輸送層セキュリティ（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] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン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] 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月。
[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.、Newman、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] Phillips、A。およびM. Davis、「言語タグのマッチング」、BCP 47、RFC 4647、2006年9月。
[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月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595] Newman、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. Ko、「国際化された電子メールの概要とフレームワーク」、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. Menon-Sen、「郵便局プロトコル（POP3）シンプルな認証とセキュリティレイヤー（SASL）認証メカニズム」、RFC 5034、2007年7月。
[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月。
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チャーセットを使用して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コマンドがない場合、ネイティブUTF-8メッセージのダウンコンバージョンは必須ですが、サーバーは「電子メールアドレスの国際化にダウングレードメカニズム」[RFC5504]を使用する必要はありません。クライアントはUTF-8サポートと、輸送中に格下げされたUTF-8メッセージをインテリジェントに処理する（例：表示および返信）にアップグレードされるため、ローカルメールストアのメッセージを処理することができればより良いです。ポップサーバーによって格下げされました。これは、POPサーバーがSMTPサーバーと同じメカニズムを使用してメッセージをダウングレードする場合に可能です。
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
ランドールゲレンズクアルコムIncorporated 5775モアハウスドライブサンディエゴ、カリフォルニア州92651米国
EMail: rg+ietf@qualcomm.com
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016-6347 US
クリスニューマンサンマイクロシステムズ800ロイヤルオークスモンロビア、CA 91016-6347 US
EMail: chis.newman@sun.com