draft-ietf-eai-rfc5721bis-08.txt   rfc6856.txt 
Network Working Group R. Gellens Internet Engineering Task Force (IETF) R. Gellens
Internet-Draft QUALCOMM Incorporated Request for Comments: 6856 QUALCOMM Incorporated
Obsoletes: 5721 (if approved) C. Newman Obsoletes: 5721 C. Newman
Intended status: Standards Track Oracle Category: Standards Track Oracle
Expires: April 25, 2013 J. Yao ISSN: 2070-1721 J. Yao
CNNIC CNNIC
K. Fujiwara K. Fujiwara
JPRS JPRS
October 22, 2012 March 2013
POP3 Support for UTF-8 Post Office Protocol Version 3 (POP3) Support for UTF-8
draft-ietf-eai-rfc5721bis-08.txt
Abstract Abstract
This specification extends the Post Office Protocol version 3 (POP3) This specification extends the Post Office Protocol version 3 (POP3)
to support UTF-8 encoded international string in user names, to support international strings encoded in UTF-8 in usernames,
passwords, mail addresses, message headers, and protocol-level passwords, mail addresses, message headers, and protocol-level text
textual strings. strings.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 25, 2013. 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/rfc6856.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 36
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 4 2. "UTF8" Capability . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 4 2.1. The "UTF8" Command . . . . . . . . . . . . . . . . . . . . 5
2.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 6 2.2. USER Argument to "UTF8" Capability . . . . . . . . . . . . 6
3. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 6 3. "LANG" Capability . . . . . . . . . . . . . . . . . . . . . . 7
4. Non-ASCII character Maildrops . . . . . . . . . . . . . . . . 9 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7
5. UTF8 Response Code . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Non-ASCII Character Maildrops . . . . . . . . . . . . . . . . 9
5. "UTF8" Response Code . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11
8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11
8.5. draft-ietf-eai-rfc5721bis: Version 04 . . . . . . . . . . 11
8.6. draft-ietf-eai-rfc5721bis: Version 05 . . . . . . . . . . 11
8.7. draft-ietf-eai-rfc5721bis: Version 06 . . . . . . . . . . 11
8.8. draft-ietf-eai-rfc5721bis: Version 07 . . . . . . . . . . 11
8.9. draft-ietf-eai-rfc5721bis: Version 08 . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document forms part of the Email Address Internationalization This document forms part of the Email Address Internationalization
protocols described in the Email Address Internationalization protocols described in the Email Address Internationalization
Framework document [RFC6530]. As part of the overall Email Address Framework document [RFC6530]. As part of the overall Email Address
Internationalization work, email messages could be transmitted and Internationalization work, email messages can be transmitted and
delivered containing Unicode string encoded in UTF-8 in the header delivered containing a Unicode string encoded in UTF-8 in the header
and/or body, and maildrops that are accessed using POP3 [RFC1939] and/or body, and maildrops that are accessed using POP3 [RFC1939]
might natively store UTF-8. might natively store Unicode characters.
This specification extends POP3 [RFC1939] using the POP3 extension This specification extends POP3 using the POP3 extension mechanism
mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers, [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers and bodies
and bodies (e.g., transferred using 8-bit Content Transfer Encoding) (e.g., transferred using 8-bit content-transfer-encoding) as
as described in "Internationalized Email Headers" [RFC6532]. It also described in "Internationalized Email Headers" [RFC6532]. It also
adds a mechanism to support login names and passwords containing adds a mechanism to support login names and passwords containing a
UTF-8 string and a mechanism to support UTF-8 string in protocol UTF-8 string (see Section 1.1 below), a mechanism to support UTF-8
level response strings as well as the ability to negotiate a language strings in protocol-level response strings, and the ability to
for such response strings. negotiate a language for such response strings.
This specification also adds a new response code to indicate that a This specification also adds a new response code to indicate that a
message was not delivered because it required UTF-8 mode discussed in message was not delivered because it required UTF-8 mode (as
section 2 and the server was unable or unwilling to create and discussed in Section 2) and the server was unable or unwilling to
deliver a variant form of the message as discussed in Section 7 of create and deliver a surrogate form of the message as discussed in
[I-D.ietf-eai-5738bis]. Section 7 of "IMAP Support for UTF-8" [RFC6855].
This specification replaces an earlier, experimental, approach to the This specification replaces an earlier, experimental, approach to the
same problem RFC 5721 [RFC5721]. same problem [RFC5721].
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
The terms "UTF-8 string" or "UTF-8 character" are used to refer to The terms "UTF-8 string" or "UTF-8 character" are used to refer to
Unicode characters, which may or may not be members of the ASCII Unicode characters, which may or may not be members of the ASCII
subset, in UTF-8 RFC3629 [RFC3629], a standard Unicode Encoding Form. repertoire, encoded in UTF-8 [RFC3629], a standard Unicode encoding
All other specialized terms used in this specification are defined in form. All other specialized terms used in this specification are
the Email Address Internationalization framework document. defined in the Email Address Internationalization framework document.
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server, respectively. If a single "C:" or "S:" label applies to server, respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol editorial clarity only and are not part of the actual protocol
exchange. exchange.
Note that examples always use ASCII characters due to limitations of Note that examples always use ASCII characters due to limitations of
this document format; otherwise, some examples for the "LANG" command the RFC format; otherwise, some examples for the "LANG" command would
may appear incorrectly. have appeared incorrectly.
2. UTF8 Capability 2. "UTF8" Capability
This specification adds a new POP3 Extension [RFC2449] capability This specification adds a new POP3 Extension [RFC2449] capability
response tag and command to specify support for header field response tag and command to specify support for header field
information in UTF-8 rather than only ASCII. The capability tag and information outside the ASCII repertoire. The capability tag and new
new command and functionality are described below. command and functionality are described below.
CAPA tag: CAPA tag:
UTF8 UTF8
Arguments with CAPA tag: Arguments with CAPA tag:
USER USER
Added Commands: Added Commands:
UTF8 UTF8
skipping to change at page 4, line 37 skipping to change at page 4, line 39
both / no both / no
Commands valid in states: Commands valid in states:
AUTHORIZATION AUTHORIZATION
Specification reference: Specification reference:
this document this document
Discussion: Discussion:
This capability adds the "UTF8" command to POP3. The UTF8 command This capability adds the "UTF8" command to POP3. The "UTF8" command
switches the session from the ASCII-only mode of RFC 1939 to UTF-8 switches the session from the ASCII-only mode of POP3 [RFC1939] to
mode. The UTF-8 mode means that, all messages transmitted between UTF-8 mode. The UTF-8 mode means that all messages transmitted
servers and clients are UTF-8 strings, and both servers and clients between servers and clients are UTF-8 strings, and both servers and
can send and accept UTF-8 string. clients can send and accept UTF-8 strings.
2.1. The UTF8 Command 2.1. The "UTF8" Command
The UTF8 command enables UTF-8 mode. The UTF8 command has no The "UTF8" command enables UTF-8 mode. The "UTF8" command has no
parameters. parameters.
UTF-8 mode has no effect on messages in an ASCII-only maildrop. UTF-8 mode has no effect on messages in an ASCII-only maildrop.
Messages in native UTF-8 maildrops can be encoded either in UTF-8 Messages in native Unicode maildrops can be encoded in UTF-8 using
using internationalized headers [RFC6532] and/or 8bit content- internationalized headers [RFC6532], in 8bit
transfer-encoding (see MIME Section 2.8 [RFC2045]), or in ASCII. The content-transfer-encoding (see Section 2.8 of MIME [RFC2045]), in
message at maildrops can be encoded in ASCII, UTF-8, or something ASCII, or in any combination of these options. In UTF-8 mode, if the
else. In UTF-8 mode, if the character encoding format of maildrops character encoding format of maildrops is UTF-8 or ASCII, the
is UTF-8 or ASCII, the messages are sent to the client as-is; if the messages are sent to the client as is; if the character encoding
character encoding format of maildrops is format other than UTF-8 or format of maildrops is a format other than UTF-8 or ASCII, the
ASCII, the messages' encoding format SHOULD be converted to be UTF-8 messages' encoding format SHOULD be converted to be UTF-8 before they
before they are sent to the client. When UTF-8 mode has not been are sent to the client. When UTF-8 mode has not been enabled,
enabled, non-ASCII strings MUST NOT be sent to the client as-is. If character strings outside the ASCII repertoire MUST NOT be sent to
a client requests a UTF-8 message when UTF-8 mode is not enabled, the the client as is. If a client requests a UTF-8 message when UTF-8
server MUST either send the client a surrogate message that complies mode is not enabled, the server MUST either send the client a
with unextended POP and Internet Mail Format without UTF-8 mode surrogate message that complies with unextended POP and Internet Mail
support, or fail the request with a -ERR response. See Format without UTF-8 mode support, or fail the request with an -ERR
[I-D.ietf-eai-5738bis], Section 7, for information about creating a response. See Section 7 of "IMAP Support for UTF-8" [RFC6855] for
surrogate message, and for a discussion of potential issues. Section information about creating a surrogate message and for a discussion
5 of this document discusses UTF8 response codes. The server MAY of potential issues. Section 5 of this document discusses "UTF8"
respond to the UTF8 command with an -ERR response. response codes. The server MAY respond to the "UTF8" command with an
-ERR response.
Note that even in UTF-8 mode, MIME binary content-transfer-encoding Note that even in UTF-8 mode, MIME binary content-transfer-encoding
as defined in MIME Section 6.2 [RFC2045] is still not permitted. as defined in Section 6.2 of MIME [RFC2045] is still not permitted.
MIME 8bit content-transfer-encoding (8BITMIME) [RFC6152] is obviously MIME 8bit content-transfer-encoding (8BITMIME) [RFC6152] is obviously
allowed. allowed.
The octet count (size) of a message reported in a response to the 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 "LIST" command SHOULD match the actual number of octets sent in a
response (not counting byte-stuffing). Sizes reported elsewhere, "RETR" response (not counting byte-stuffing). Sizes reported
such as in STAT responses and non-standardized, free-form text in elsewhere, such as in "STAT" responses and non-standardized,
positive status indicators (following "+OK") need not be accurate, free-form text in positive status indicators (following "+OK") need
but it is preferable if they were. not be accurate, but it is preferable if they are.
Normal operation for maildrops that natively support non-ASCII Normal operation for maildrops that natively support non-ASCII
characters will be for both servers and clients to support the characters will be for both servers and clients to support the
extension discussed in this specification. Upgrading of both clients extension discussed in this specification. Upgrading both clients
and servers is the only fully satisfactory way to support the and servers is the only fully satisfactory way to support the
capabilities offered by the "UTF8" extension and SMTPUTF8 mail more capabilities offered by the "UTF8" extension and SMTPUTF8 mail more
generally. Servers must, however, anticipate the possibility of a generally. Servers must, however, anticipate the possibility of a
client attempting to access a message that requires this extension client attempting to access a message that requires this extension
without having issued the "UTF8" command. There are no completely without having issued the "UTF8" command. There are no completely
satisfactory responses for that case other than upgrading the client satisfactory responses for this case other than upgrading the client
to support this specification. One solution, unsatisfactory because to support this specification. One solution, unsatisfactory because
the user may be confused by being able to access the message through the user may be confused by being able to access the message through
some means and not others, is that a server MAY choose to reject the some means and not others, is that a server MAY choose to reject the
command to retrieve the message as discussed in Section 5. Other command to retrieve the message as discussed in Section 5. Other
alternatives, including the possibility of creating and delivering alternatives, including the possibility of creating and delivering a
variant form of the message, are discussed in Section 7 of surrogate form of the message, are discussed in Section 7 of "IMAP
[I-D.ietf-eai-5738bis]. Support for UTF-8" [RFC6855].
Clients MUST NOT issue the STLS command [RFC2595] after issuing UTF8; Clients MUST NOT issue the "STLS" command [RFC2595] after issuing
servers MAY (but are not required to) enforce this by rejecting with UTF8; servers MAY (but are not required to) enforce this by rejecting
an "-ERR" response an STLS command issued subsequent to a successful with an -ERR response an "STLS" command issued subsequent to a
UTF8 command. (Because this is a protocol error as opposed to a successful "UTF8" command. (Because this is a protocol error as
failure based on conditions, an extended response code [RFC2449] is opposed to a failure based on conditions, an extended response code
not specified.) [RFC2449] is not specified.)
2.2. USER Argument to UTF8 Capability 2.2. USER Argument to "UTF8" Capability
If the USER argument is included with this capability, it indicates If the USER argument is included with this capability, it indicates
that the server accepts UTF-8 user names and passwords. that the server accepts UTF-8 usernames and passwords.
Servers that include the USER argument in the UTF8 capability Servers that include the USER argument in the "UTF8" capability
response SHOULD apply SASLprep [RFC4013] or one of its standards- response SHOULD apply SASLprep [RFC4013] or one of its Standards
track successors to the arguments of the USER and PASS commands. Track successors to the arguments of the "USER" and "PASS" commands.
A client or server that supports APOP and permits UTF-8 in user names A client or server that supports APOP and permits UTF-8 in usernames
or passwords MUST apply SASLprep [RFC4013] or one of its standards- or passwords MUST apply SASLprep or one of its Standards Track
track successors to the user name and password used to compute the successors to the username and password used to compute the APOP
APOP digest. digest.
When applying SASLprep [RFC4013], servers MUST reject UTF-8 user When applying SASLprep, servers MUST reject UTF-8 usernames or
names or passwords that contain a UTF-8 character listed in Section passwords that contain a UTF-8 character listed in Section 2.3 of
2.3 of SASLprep. When applying SASLprep to the USER argument, the SASLprep. When applying SASLprep to the USER argument, the PASS
PASS argument, or the APOP username argument, a compliant server or argument, or the APOP username argument, a compliant server or client
client MUST treat them as a query string [RFC3454]. When applying MUST treat them as a query string [RFC3454]. When applying SASLprep
SASLprep to the APOP password argument, a compliant server or client to the APOP password argument, a compliant server or client MUST
MUST treat them as a stored string [RFC3454]. treat them as a stored string [RFC3454].
The client does not need to issue the UTF8 command prior to using If the server includes the USER argument in the UTF8 capability
UTF-8 in authentication. However, clients MUST NOT use UTF-8 string response, the client MAY use UTF-8 characters with a "USER", "PASS",
in USER, PASS, or APOP commands unless the USER argument is included or "APOP" command; the client MAY do so before issuing the "UTF8"
in the UTF8 capability response. command. Clients MUST NOT use UTF-8 characters when authenticating
if the server did not include the USER argument in the UTF8
capability response.
The server MUST reject UTF-8 user names or passwords that fail to The server MUST reject UTF-8 usernames or passwords that fail to
comply with the formal syntax in UTF-8 [RFC3629]. comply with the formal syntax in UTF-8 [RFC3629].
Use of UTF-8 string in the AUTH command is governed by the POP3 SASL Use of UTF-8 strings in the "AUTH" command is governed by the POP3
[RFC5034] mechanism. SASL [RFC5034] mechanism.
3. LANG Capability 3. "LANG" Capability
This document adds a new POP3 Extension [RFC2449] capability response This document adds a new POP3 extension [RFC2449] capability response
tag to indicate support for a new command: LANG. The capability tag tag to indicate support for a new command: "LANG".
and new command are described below.
3.1. Definition
The capability tag and new command are described below.
CAPA tag: CAPA tag:
LANG LANG
Arguments with CAPA tag: Arguments with CAPA tag:
none none
Added Commands: Added Commands:
LANG LANG
skipping to change at page 7, line 23 skipping to change at page 7, line 35
Announced states / possible differences: Announced states / possible differences:
both / no both / no
Commands valid in states: Commands valid in states:
AUTHORIZATION, TRANSACTION AUTHORIZATION, TRANSACTION
Specification reference: Specification reference:
this document this document
Discussion: 3.2. Discussion
POP3 allows most +OK and -ERR server responses to include human- POP3 allows most +OK and -ERR server responses to include human-
readable text that, in some cases, might be presented to the user. readable text that, in some cases, might be presented to the user.
But that text is limited to ASCII by the POP3 specification But that text is limited to ASCII by the POP3 specification
[RFC1939]. The LANG capability and command permit a POP3 client to [RFC1939]. The "LANG" capability and command permit a POP3 client to
negotiate which language the server uses when sending human-readable negotiate which language the server uses when sending human-readable
text. text.
The LANG command requests that human-readable text included in all The "LANG" command requests that human-readable text included in all
subsequent +OK and -ERR responses be localized to a language matching subsequent +OK and -ERR responses be localized to a language matching
the language range argument (the "Basic Language Range" as described the language range argument (the "basic language range" as described
by [RFC4647]). If the command succeeds, the server returns a +OK by the "Matching of Language Tags" [RFC4647]). If the command
response followed by a single space, the exact language tag selected, succeeds, the server returns a +OK response followed by a single
another space. Human-readable text in the appropriate language then space, the exact language tag selected, and another space. Human-
appears in the rest of the line. This and subsequent protocol-level readable text in the appropriate language then appears in the rest of
human-readable text is encoded in the UTF-8 charset. the line. This, and subsequent protocol-level human-readable text,
is encoded in the UTF-8 charset.
If the command fails, the server returns an -ERR response and If the command fails, the server returns an -ERR response and
subsequent human-readable response text continues to use the language subsequent human-readable response text continues to use the language
that was previously used. that was previously used.
If the client issues a LANG command with the special "*" language If the client issues a "LANG" command with the special "*" language
range argument, it indicates a request to use a language designated range argument, it indicates a request to use a language designated
as preferred by the server administrator. The preferred language MAY as preferred by the server administrator. The preferred language MAY
vary based on the currently active user. vary based on the currently active user.
If no argument is given and the POP3 server issues a positive If no argument is given and the POP3 server issues a positive
response, that response will usually consist of multi-lines. After response, that response will usually consist of multiple lines.
the initial +OK, for each language tag the server supports, the POP3 After the initial +OK, for each language tag the server supports, the
server responds with a line for that language. This line is called a POP3 server responds with a line for that language. This line is
"language listing". called a "language listing".
In order to simplify parsing, all POP3 servers are required to use a In order to simplify parsing, all POP3 servers are required to use a
certain format for language listings. A language listing consists of certain format for language listings. A language listing consists of
the language tag [RFC5646] of the message, optionally followed by a the language tag [RFC5646] of the message, optionally followed by a
single space and a human-readable description of the language in the single space and a human-readable description of the language in the
language itself, using the UTF-8 charset. There are no specific language itself, using the UTF-8 charset. There is no specific order
listing order of languages, which may depend on configuration or to the listing of languages; the order may depend on configuration or
implementation. implementation.
Examples: 3.3. Examples
Examples for "LANG" capability usage are shown below.
Note that some examples do not include the correct character Note that some examples do not include the correct character
accents due to limitations of this document format. accents due to limitations of the RFC format.
C: USER karen C: USER karen
S: +OK Hello, karen S: +OK Hello, karen
C: PASS password C: PASS password
S: +OK karen's maildrop contains 2 messages (320 octets) S: +OK karen's maildrop contains 2 messages (320 octets)
Client requests deprecated MUL language. Server replies Client requests deprecated MUL language [ISO639-2]. Server
with -ERR response. replies with -ERR response.
C: LANG MUL C: LANG MUL
S: -ERR invalid language MUL S: -ERR invalid language MUL
A LANG command with no parameters is a request for A LANG command with no parameters is a request for
a language listing. a language listing.
C: LANG C: LANG
S: +OK Language listing follows: S: +OK Language listing follows:
S: en English S: en English
S: en-boont English Boontling dialect S: en-boont English Boontling dialect
S: de Deutsch S: de Deutsch
S: it Italiano S: it Italiano
S: es Espanol S: es Espanol
skipping to change at page 8, line 50 skipping to change at page 9, line 23
S: es Espanol S: es Espanol
S: sv Svenska S: sv Svenska
S: . S: .
A request for a language listing might fail. A request for a language listing might fail.
C: LANG C: LANG
S: -ERR Server is unable to list languages S: -ERR Server is unable to list languages
Once the client selects the language, all responses will be in Once the client selects the language, all responses will be in
that language, starting with the response to the LANG command. that language, starting with the response to the "LANG" command.
C: LANG es C: LANG es
S: +OK es Idioma cambiado S: +OK es Idioma cambiado
If a server returns an -ERR response to a LANG command If a server returns an -ERR response to a "LANG" command
that specifies a primary language, the current language that specifies a primary language, the current language
for responses remains in effect. for responses remains in effect.
C: LANG uga C: LANG uga
S: -ERR es Idioma <<UGA>> no es conocido S: -ERR es Idioma <<UGA>> no es conocido
C: LANG sv C: LANG sv
S: +OK sv Kommandot "LANG" lyckades S: +OK sv Kommandot "LANG" lyckades
C: LANG * C: LANG *
S: +OK es Idioma cambiado S: +OK es Idioma cambiado
4. Non-ASCII character Maildrops 4. Non-ASCII Character Maildrops
When a POP3 server uses a native non-ASCII character maildrop, it is When a POP3 server uses a native non-ASCII character maildrop, it is
the responsibility of the server to comply with the POP3 base the responsibility of the server to comply with the POP3 base
specification [RFC1939] and Internet Message Format [RFC5322] when specification [RFC1939] and Internet Message Format [RFC5322] when
not in UTF-8 mode. When the server is not in UTF-8 mode and the not in UTF-8 mode. When the server is not in UTF-8 mode and the
message requires that mode, requests to download the message MAY be message requires that mode, requests to download the message MAY be
rejected (as specified in the next section) or the various other rejected (as specified in the next section) or the various
alternatives outlined in Section 2.1 above, including creation and alternatives outlined in Section 2.1 above, including creation and
delivery of variations on the original message, MAY be considered. delivery of surrogates for the original message, MAY be considered.
5. UTF8 Response Code 5. "UTF8" Response Code
Per "POP3 Extension Mechanism" [RFC2449], this document adds a new Per "POP3 Extension Mechanism" [RFC2449], this document adds a new
response code: UTF8, described below. response code: UTF8, described below.
Complete response code: Complete response code:
UTF8 UTF8
Valid for responses: Valid for responses:
-ERR -ERR
Valid for commands: Valid for commands:
LIST, TOP, RETR LIST, TOP, RETR
Response code meaning and expected client behavior: Response code meaning and expected client behavior:
The "UTF8" response code indicates that a failure is due to a
request for message content that contains a UTF-8 string when the
client is not in UTF-8 mode.
The UTF8 response code indicates that a failure is due to a request The client MAY reissue the command after entering UTF-8 mode.
when not in UTF-8 mode for message content containing UTF-8 string.
The client MAY reissue the command after entering UTF-8 mode.
6. IANA Considerations 6. IANA Considerations
Section 2 and 3 of this specification update two capabilities ("UTF8" Sections 2 and 3 of this specification update two capabilities
and "LANG") to the POP3 capability registry [RFC2449]. ("UTF8" and "LANG") in the POP3 capability registry [RFC2449].
Section 5 of this specification also adds one new response code Section 5 of this specification adds one new response code ("UTF8")
("UTF8") to the POP3 response codes registry [RFC2449]. to the POP3 response codes registry [RFC2449].
7. Security Considerations 7. Security Considerations
The security considerations of UTF-8 [RFC3629], SASLprep [RFC4013] The security considerations of UTF-8 [RFC3629], SASLprep [RFC4013],
and Unicode Format for Network Interchange [RFC5198] apply to this and the Unicode Format for Network Interchange [RFC5198] apply to
specification, particularly with respect to use of UTF-8 in user this specification, particularly with respect to use of UTF-8 strings
names and passwords. in usernames and passwords.
The "LANG *" command might reveal the existence and preferred The "LANG *" command might reveal the existence and preferred
language of a user to an active attacker probing the system if the language of a user to an active attacker probing the system if the
active language changes in response to the USER, PASS, or APOP active language changes in response to the "USER", "PASS", or "APOP"
commands prior to validating the user's credentials. Servers are commands prior to validating the user's credentials. Servers are
strongly advised to implement a configuration to prevent this strongly advised to implement a configuration to prevent this
exposure. exposure.
It is possible for a man-in-the-middle attacker to insert a LANG It is possible for a man-in-the-middle attacker to insert a "LANG"
command in the command stream, thus making protocol-level diagnostic command in the command stream, thus, making protocol-level diagnostic
responses unintelligible to the user. A mechanism to protect the responses unintelligible to the user. A mechanism to protect the
integrity of the session can be used to defeat such attacks. For integrity of the session can be used to defeat such attacks. For
example, a client can issue the STLS command [RFC2595] before issuing example, a client can issue the "STLS" command [RFC2595] before
the LANG command. issuing the "LANG" command.
As with other internationalization upgrades, modifications to server As with other internationalization upgrades, modifications to server
authentication code (in this case, to support non-ASCII strings) authentication code (in this case, to support non-ASCII strings) need
needs to be done with care to avoid introducing vulnerabilities (for to be done with care to avoid introducing vulnerabilities (for
example, in string parsing or matching). This is particularly example, in string parsing or matching). This is particularly
important if the native databases or mailstore of the operating important if the native databases or mailstore of the operating
system use some character set or encoding other than Unicode in system use some character set or encoding other than Unicode in
UTF-8. UTF-8.
8. Change History 8. References
8.1. draft-ietf-eai-rfc5721bis: Version 00
following the new charter
8.2. draft-ietf-eai-rfc5721bis: Version 01
refine the texts
8.3. draft-ietf-eai-rfc5721bis: Version 02
update the texts based on Joseph's comments
8.4. draft-ietf-eai-rfc5721bis: Version 03
improve the texts
text instructing servers to either downconvert or reject
new UTF-8 response code for use
8.5. draft-ietf-eai-rfc5721bis: Version 04
improve the texts
8.6. draft-ietf-eai-rfc5721bis: Version 05
updated according to jabber interim meeting result
updated according to john and apparea's review comments
8.7. draft-ietf-eai-rfc5721bis: Version 06
improve the texts, updated section 3.2 to provide for SASL successor
specs.
8.8. draft-ietf-eai-rfc5721bis: Version 07
updated according to John's comments
8.9. draft-ietf-eai-rfc5721bis: Version 08
improve the texts
9. References 8.1. Normative References
9.1. Normative References [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. Shen, "IMAP [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Support for UTF-8", draft-ietf-eai-5738bis-03 Extensions (MIME) Part One: Format of Internet Message
(work in progress), December 2011. Bodies", RFC 2045, November 1996.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
- Version 3", STD 53, RFC 1939, May 1996. Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, November 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Internet Mail Extensions (MIME) Part One: Requirement Levels", BCP 14, RFC 2119, March 1997.
Format of Internet Message Bodies", RFC 2045, [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3
November 1996. Extension Mechanism", RFC 2449, November 1998.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Extensions) Part Three: Message Header Internationalized Strings ("stringprep")", RFC 3454,
Extensions for Non-ASCII Text", RFC 2047, December 2002.
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Indicate Requirement Levels", BCP 14, 10646", STD 63, RFC 3629, November 2003.
RFC 2119, March 1997.
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
"POP3 Extension Mechanism", RFC 2449, Names and Passwords", RFC 4013, February 2005.
November 1998.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
Internationalized Strings ("stringprep")", BCP 47, RFC 4647, September 2006.
RFC 3454, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
of ISO 10646", STD 63, RFC 3629, Interchange", RFC 5198, March 2008.
November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
for User Names and Passwords", RFC 4013, October 2008.
February 2005.
[RFC4647] Phillips, A. and M. Davis, "Matching of [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Language Tags", BCP 47, RFC 4647, Languages", BCP 47, RFC 5646, September 2009.
September 2006.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
for Network Interchange", RFC 5198, Service Extension for 8-bit MIME Transport", STD 71,
March 2008. RFC 6152, March 2011.
[RFC5322] Resnick, P., Ed., "Internet Message Format", [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
RFC 5322, October 2008. Internationalized Email", RFC 6530, February 2012.
[RFC5646] Phillips, A. and M. Davis, "Tags for [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Identifying Languages", BCP 47, RFC 5646, Email Headers", RFC 6532, February 2012.
September 2009.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. [RFC6855] Resnick, P., Newman, C., and S. Shen, "IMAP Support for
Crocker, "SMTP Service Extension for 8-bit UTF-8", RFC 6855, March 2013.
MIME Transport", STD 71, RFC 6152,
March 2011.
[RFC6530] Klensin, J. and Y. Ko, "Overview and 8.2. Informative References
Framework for Internationalized Email",
RFC 6530, February 2012.
[RFC6532] Yang, A., Steele, S., and N. Freed, [ISO639-2] International Organization for Standardization, "ISO
"Internationalized Email Headers", RFC 6532, 639-2:1998. Codes for the representation of names of
February 2012. languages -- Part 2: Alpha-3 code", October 1998.
9.2. Informative References [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
ACAP", RFC 2595, June 1999. RFC 2595, June 1999.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office
Office Protocol (POP3) Simple Authentication Protocol (POP3) Simple Authentication and Security Layer
and Security Layer (SASL) Authentication (SASL) Authentication Mechanism", RFC 5034, July 2007.
Mechanism", RFC 5034, July 2007.
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8",
UTF-8", RFC 5721, February 2010. RFC 5721, February 2010.
Appendix A. Design Rationale Appendix A. Design Rationale
This non-normative section discusses the reasons behind some of the This non-normative section discusses the reasons behind some of the
design choices in the above specification. design choices in this specification.
Due to interoperability problems with RFC 2047 and limited deployment Due to interoperability problems with the MIME Message Header
of RFC 2231, it is hoped these 7-bit encoding mechanisms can be Extensions [RFC2047] and limited deployment of the extended MIME
deprecated in the future when UTF-8 header support becomes prevalent. parameter encodings [RFC2231], it is hoped these 7-bit encoding
mechanisms can be deprecated in the future when UTF-8 header support
becomes prevalent.
The USER capability (Section 2.2) and hence the upgraded USER command The USER capability (Section 2.2) and hence the upgraded "USER"
and additional support for non-ASCII credentials, are optional command and additional support for non-ASCII credentials, are
because the implementation burden of SASLprep [RFC4013] is not well optional because the implementation burden of SASLprep [RFC4013] is
understood, and mandating such support in all cases could negatively not well understood, and mandating such support in all cases could
impact deployment. negatively impact deployment.
Appendix B. Acknowledgments Appendix B. Acknowledgments
Thanks to John Klensin, Joseph Yee, Tony Hansen, Alexey Melnikov and Thanks to John Klensin, Joseph Yee, Tony Hansen, Alexey Melnikov, and
other Email Address Internationalization working group participants other Email Address Internationalization working group participants
who provided helpful suggestions and interesting debate that improved who provided helpful suggestions and interesting debate that improved
this specification. this specification.
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
QUALCOMM Incorporated QUALCOMM Incorporated
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92651 San Diego, CA 92651
US USA
EMail: rg+ietf@qualcomm.com EMail: rg+ietf@qualcomm.com
Chris Newman Chris Newman
Oracle Oracle
800 Royal Oaks 800 Royal Oaks
Monrovia, CA 91016-6347 Monrovia, CA 91016-6347
US USA
EMail: chris.newman@oracle.com EMail: chris.newman@oracle.com
Jiankang YAO Jiankang YAO
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing Beijing
China
Phone: +86 10 58813007 Phone: +86 10 58813007
EMail: yaojk@cnnic.cn EMail: yaojk@cnnic.cn
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Tokyo Tokyo
Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
EMail: fujiwara@jprs.co.jp EMail: fujiwara@jprs.co.jp
 End of changes. 97 change blocks. 
298 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/