draft-ietf-eai-rfc5721bis-04.txt   draft-ietf-eai-rfc5721bis-05.txt 
Network Working Group R. Gellens Network Working Group R. Gellens
Internet-Draft QUALCOMM Incorporated Internet-Draft QUALCOMM Incorporated
Obsoletes: 5721 (if approved) C. Newman Obsoletes: 5721 (if approved) C. Newman
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: October 12, 2012 J. Yao Expires: December 14, 2012 J. Yao
CNNIC CNNIC
K. Fujiwara K. Fujiwara
JPRS JPRS
April 10, 2012 June 12, 2012
POP3 Support for UTF-8 POP3 Support for UTF-8
draft-ietf-eai-rfc5721bis-04.txt draft-ietf-eai-rfc5721bis-05.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 un-encoded international characters in user names, to support un-encoded international characters in user names,
passwords, mail addresses, message headers, and protocol-level passwords, mail addresses, message headers, and protocol-level
textual strings. textual strings.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2012. This Internet-Draft will expire on December 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 4 2. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 4
3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 7 3.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 7
3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 9 3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 8
4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9 4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9
5. UTF-8 Response Code . . . . . . . . . . . . . . . . . . . . . 9 5. UTF8 Response Code . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 11 8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10
8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 11 8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10
8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11 8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 10
8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11 8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 10
8.5. draft-ietf-eai-rfc5721bis: Version 04 . . . . . . . . . . 11 8.5. draft-ietf-eai-rfc5721bis: Version 04 . . . . . . . . . . 11
8.6. draft-ietf-eai-rfc5721bis: Version 05 . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12
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
(EAI) protocols described in the EAI Framework document [RFC6530]. (EAI) protocols described in the EAI Framework document [RFC6530].
As part of the overall EAI work, email messages may be transmitted As part of the overall EAI work, email messages could be transmitted
and delivered containing un-encoded UTF-8 characters in the header and delivered containing un-encoded UTF-8 characters in the header
and/or body, and mail drops 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 UTF-8.
This specification extends POP3 [RFC1939] using the POP3 extension This specification extends POP3 [RFC1939] using the POP3 extension
mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers, mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers,
and bodies (e.g., transferred using 8-bit Content Transfer Encoding) and bodies (e.g., transferred using 8-bit Content Transfer Encoding)
as described in "Internationalized Email Headers" [RFC6532]. It also as 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
UTF-8 characters, and a mechanism to support UTF-8 characters in UTF-8 characters, and a mechanism to support UTF-8 characters in
protocol level response strings as well as the ability to negotiate a protocol level response strings as well as the ability to negotiate a
language for such response strings. 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 could not be returned because it requires UTF-8 mode and the message could not be returned because it requires UTF-8 mode and the
server is unwilling to down-convert. server is unwilling to create and deliver variant form of the message
discussed in Section 7 of [I-D.ietf-eai-5738bis].
Within this specification, the term "down-convert" refers to the
process of modifying a message containing UTF-8 headers [RFC6532] 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. The method of down-convert is specified
by "Post-delivery Message Downgrading for Internationalized Email
Messages" [popimap-downgrade] and EAI: Simplified POP/IMAP
downgrading [I-D.ietf-eai-simpledowngrade].
This specification replaces an earlier, experimental, approach to the This specification replaces an earlier, experimental, approach to the
same problem RFC 5721 [RFC5721]. Section 6 of [RFC6530] describes same problem RFC 5721 [RFC5721]. Section 6 of [RFC6530] describes
the changes in approach between RFC 5721 [RFC5721] and this the changes in approach between RFC 5721 [RFC5721] and this
specification. specification.
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].
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 7-bit ASCII characters due to Note that examples always use 7-bit ASCII characters due to
limitations of this document format; in particular, some examples for limitations of this document format; Otherwise, some examples for the
the "LANG" command may appear silly as a result. "LANG" command may appear incorrectly as a result.
2. LANG Capability 2. LANG Capability
Per "POP3 Extension Mechanism" [RFC2449], this document adds a new Per "POP3 Extension Mechanism" [RFC2449], this document adds a new
capability response tag to indicate support for a new command: LANG. capability response tag to indicate support for a new command: LANG.
The capability tag and new command are described below. The capability tag and new command are described below.
CAPA tag: CAPA tag:
LANG LANG
skipping to change at page 4, line 46 skipping to change at page 4, line 41
Discussion: 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.
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.
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 [RFC4647]). If the command succeeds, the server returns a +OK
response followed by a single space, the exact language tag selected, 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 another space, and the rest of the line is human-readable text in the
appropriate language. This and subsequent protocol-level human- appropriate language. This and subsequent protocol-level human-
readable text is encoded in the UTF-8 charset. 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 active (typically i-default). that was previously active.
The special "*" language range argument indicates a request to use a The special "*" language range argument indicates a request to use a
language designated as preferred by the server administrator. The language designated as preferred by the server administrator. The
preferred language MAY vary based on the currently active user. preferred language MAY 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, then the response given is multi-line. After the initial response, then the response given is multi-line. After the initial
+OK, for each language tag the server supports, the POP3 server +OK, for each language tag the server supports, the POP3 server
responds with a line for that language. This line is called a responds with a line for that language. This line is called a
"language listing". "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. language itself, using the UTF-8 charset. There are no specific
listing order of languages, which may depend on configuration or
implementation.
Examples: Examples:
< 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 this document format. >
< The server defaults to using English i-default responses until
the client explicitly changes the language. >
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. Server replies
with -ERR response. > with -ERR response. >
C: LANG MUL C: LANG MUL
S: -ERR invalid language MUL S: -ERR invalid language MUL
skipping to change at page 6, line 14 skipping to change at page 5, line 50
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
S: sv Svenska S: sv Svenska
S: i-default Default language
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 changes 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 does not support the requested primary language, < If a server does not support the requested primary language,
responses will continue to be returned in the current language responses will continue to be returned in the current language
the server is using. > the server is using. >
C: LANG uga C: LANG uga
skipping to change at page 7, line 46 skipping to change at page 7, line 31
Maildrops can natively store UTF-8 or be limited to ASCII. UTF-8 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 mode has no effect on messages in an ASCII-only maildrop. Messages
in native UTF-8 maildrops can be ASCII or UTF-8 using in native UTF-8 maildrops can be ASCII or UTF-8 using
internationalized headers [RFC6532] and/or 8bit content-transfer- internationalized headers [RFC6532] and/or 8bit content-transfer-
encoding, as defined in MIME Section 2.8 [RFC2045]. In UTF-8 mode, 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 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 conversion). When not in UTF-8 mode, UTF-8 messages in a native
UTF-8 maildrop MUST NOT be sent to the client as-is. If a client UTF-8 maildrop MUST NOT be sent to the client as-is. If a client
requests a UTF-8 message when not in UTF-8 mode, the server MUST requests a UTF-8 message when not in UTF-8 mode, the server MUST
either down-convert (downgrade) the message content it sends to the either create the message content variant (discussed in Section 7 of
client to comply with unextended POP and Internet Mail Format without [I-D.ietf-eai-5738bis]) it sends to the client to comply with
UTF-8 mode support, or fail the request with a -ERR response unextended POP and Internet Mail Format without UTF-8 mode support,
containing the UTF-8 response code (see section 5). The UTF8 command or fail the request with a -ERR response containing the UTF-8
MAY fail. response code (see section 5). The UTF8 command MAY fail.
Note that even in UTF-8 mode, MIME binary content-transfer-encoding Note that even in UTF-8 mode, MIME binary content-transfer-encoding
is still not permitted. as defined in MIME Section 6.2 [RFC2045] is still not permitted.
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 RETR
response (not counting byte-stuffing). Sizes reported elsewhere, response (not counting byte-stuffing). Sizes reported elsewhere,
such as in STAT responses and non-standardized, free-form text in such as in STAT responses and non-standardized, free-form text in
positive status indicators (following "+OK") need not be accurate, positive status indicators (following "+OK") need not be accurate,
but it is preferable if they were. but it is preferable if they were.
Mail stores are either ASCII or native UTF-8, and clients either Normal operation for UTF-8 maildrops will be for both servers and
issue the UTF8 command or not. The message needs converting only clients to support the extension discussed in this specification.
when it is native UTF-8 and the client has not issued the UTF8 Upgrading of both clients and servers is the only fully satisfactory
command, in which case the server MAY choose to down-convert it or way to support the capabilities offered by the "UTF8" extension and
reject the command which requested the message with the new UTF-8 SMTPUTF8 mail more generally. Servers must, however, anticipate the
response code (see Section 5). The down-converted message may be possibility of a client attempting to access a message that requires
larger. The server may choose various strategies regarding down- this extension without having issued the "UTF8" command. There are
convert, which include when to down-convert, whether to cache or no completely satisfactory responses for that case other than
store the down-converted form of a message (and if so, for how long), upgrading the client to support this specification. One solution,
and whether to calculate or retain the size of a down-converted unsatisfactory because the user may be confused by being able to
message independently of the down-converted content. If the server access the message through some means and not others, is that a
does not have immediate access to the accurate down-converted size, server MAY choose to reject the command to retrieve the message as
it may be faster to estimate rather than calculate it. Servers are discussed in Section 5. Other alternatives, including the
expected to normally follow the RFC 1939 [RFC1939] text on using the possibility of creating and delivering variant form of the message,
"exact size" in a scan listing, but there may be situations with are discussed in Section 7 of [I-D.ietf-eai-5738bis].
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.
Clients MUST NOT issue the STLS command [RFC2595] after issuing UTF8; Clients MUST NOT issue the STLS command [RFC2595] after issuing UTF8;
servers MAY (but are not required to) enforce this by rejecting with servers MAY (but are not required to) enforce this by rejecting with
an "-ERR" response an STLS command issued subsequent to a successful an "-ERR" response an STLS command issued subsequent to a successful
UTF8 command. (Because this is a protocol error as opposed to a UTF8 command. (Because this is a protocol error as opposed to a
failure based on conditions, an extended response code [RFC2449] is failure based on conditions, an extended response code [RFC2449] is
not specified.) not specified.)
3.2. USER Argument to UTF8 Capability 3.2. USER Argument to UTF8 Capability
skipping to change at page 9, line 44 skipping to change at page 9, line 13
comply with the formal syntax in UTF-8 [RFC3629]. comply with the formal syntax in UTF-8 [RFC3629].
Use of UTF-8 characters in the AUTH command is governed by the POP3 Use of UTF-8 characters in the AUTH command is governed by the POP3
SASL [RFC5034] mechanism. SASL [RFC5034] mechanism.
4. Native UTF-8 Maildrops 4. Native UTF-8 Maildrops
When a POP3 server uses a native UTF-8 maildrop, it is the When a POP3 server uses a native UTF-8 maildrop, it is the
responsibility of the server to comply with the POP3 base 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. Mechanisms for 7-bit downgrading to help comply not in UTF-8 mode. When the server is not in UTF-8 mode and the
with the standards are described in [popimap-downgrade] and message requires that mode, requests to download the message MAY be
[I-D.ietf-eai-simpledowngrade]. The implementors MAY choose one of rejected (as specified in the next section) or the various other
them to implement downgrade. alternatives outlined in Section 3.1 above and in Section 7 of the
IMAP UTF-8 specification [draft-ietf-eai-5738bis], including creation
and delivery of variations on the original message, MAY be
considered.
5. UTF-8 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: UTF-8, 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 UTF-8 response code indicates that a failure is due to a request The UTF8 response code indicates that a failure is due to a request
when not in UTF-8 mode for message content containing UTF-8 when not in UTF-8 mode for message content containing UTF-8
characters. characters.
The client MAY reissue the command after entering UTF-8 mode (or wait The client MAY reissue the command after entering UTF-8 mode.
for the server to be in a better mood and willing to downconvert).
6. IANA Considerations 6. IANA Considerations
The section 2 and 3 of this specification update two capabilities Section 2 and 3 of this specification update two capabilities ("UTF8"
("UTF8" and "LANG") to the POP3 capability registry [RFC2449]. and "LANG") to the POP3 capability registry [RFC2449].
The section 5 of this specification also adds one new response code Section 5 of this specification also adds one new response code
("UTF-8") to the POP3 response codes registry [RFC2449]. ("UTF8") to the POP3 response codes registry [RFC2449].
7. Security Considerations 7. Security Considerations
The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013]
apply to this specification, particularly with respect to use of apply to this specification, particularly with respect to use of
UTF-8 in user names and passwords. UTF-8 in user names 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 MUST commands prior to validating the user's credentials. Servers are
implement a configuration to prevent this exposure. strongly advised to implement a configuration to prevent this
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 integrity- responses unintelligible to the user. A mechanism to protect the
protect the session, such as Transport Layer Security (TLS) [RFC2595] integrity of the session, such as , Transport Layer Security (TLS)
can be used to defeat such attacks. [RFC2595] can be used to defeat such attacks.
Modifying server authentication code (in this case, to support UTF8 Modifying server authentication code (in this case, to support UTF8
command) needs to be done with care to avoid introducing command) needs to be done with care to avoid introducing
vulnerabilities (for example, in string parsing). vulnerabilities (for example, in string parsing).
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.
8. Change History 8. Change History
8.1. draft-ietf-eai-rfc5721bis: Version 00 8.1. draft-ietf-eai-rfc5721bis: Version 00
following the new charter following the new charter
8.2. draft-ietf-eai-rfc5721bis: Version 01 8.2. draft-ietf-eai-rfc5721bis: Version 01
refine the texts refine the texts
skipping to change at page 11, line 37 skipping to change at page 11, line 9
improve the texts improve the texts
text instructing servers to either downconvert or reject text instructing servers to either downconvert or reject
new UTF-8 response code for use new UTF-8 response code for use
8.5. draft-ietf-eai-rfc5721bis: Version 04 8.5. draft-ietf-eai-rfc5721bis: Version 04
improve the texts improve the texts
9. References 8.6. draft-ietf-eai-rfc5721bis: Version 05
9.1. Normative References updated according to jabber interim meeting result
[I-D.ietf-eai-simpledowngrade] Gulbrandsen, A., "EAI: Simplified updated according to john and apparea's review comments
POP/IMAP downgrading",
draft-ietf-eai-simpledowngrade-03
(work in progress), March 2012.
[RFC1939] Myers, J. and M. Rose, "Post Office 9. References
Protocol - Version 3", STD 53,
RFC 1939, May 1996.
[RFC2045] Freed, N. and N. Borenstein, 9.1. Normative References
"Multipurpose Internet Mail
Extensions (MIME) Part One: Format of
Internet Message Bodies", RFC 2045,
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose [I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. Shen, "IMAP
Internet Mail Extensions) Part Three: Support for UTF-8", draft-ietf-eai-5738bis-03
Message Header Extensions for Non- (work in progress), December 2011.
ASCII Text", RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in [RFC1939] Myers, J. and M. Rose, "Post Office Protocol
RFCs to Indicate Requirement Levels", - Version 3", STD 53, RFC 1939, May 1996.
BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on [RFC2045] Freed, N. and N. Borenstein, "Multipurpose
Character Sets and Languages", Internet Mail Extensions (MIME) Part One:
BCP 18, RFC 2277, January 1998. Format of Internet Message Bodies", RFC 2045,
November 1996.
[RFC2449] Gellens, R., Newman, C., and L. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Lundblade, "POP3 Extension Extensions) Part Three: Message Header
Mechanism", RFC 2449, November 1998. Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC3454] Hoffman, P. and M. Blanchet, [RFC2119] Bradner, S., "Key words for use in RFCs to
"Preparation of Internationalized Indicate Requirement Levels", BCP 14,
Strings ("stringprep")", RFC 3454, RFC 2119, March 1997.
December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC2449] Gellens, R., Newman, C., and L. Lundblade,
format of ISO 10646", STD 63, "POP3 Extension Mechanism", RFC 2449,
RFC 3629, November 2003. November 1998.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Profile for User Names and Internationalized Strings ("stringprep")",
Passwords", RFC 4013, February 2005. RFC 3454, December 2002.
[RFC4647] Phillips, A. and M. Davis, "Matching [RFC3629] Yergeau, F., "UTF-8, a transformation format
of Language Tags", BCP 47, RFC 4647, of ISO 10646", STD 63, RFC 3629,
September 2006. November 2003.
[RFC5322] Resnick, P., Ed., "Internet Message [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile
Format", RFC 5322, October 2008. for User Names and Passwords", RFC 4013,
February 2005.
[RFC5646] Phillips, A. and M. Davis, "Tags for [RFC4647] Phillips, A. and M. Davis, "Matching of
Identifying Languages", BCP 47, Language Tags", BCP 47, RFC 4647,
RFC 5646, September 2009. September 2006.
[RFC6530] Klensin, J. and Y. Ko, "Overview and [RFC5322] Resnick, P., Ed., "Internet Message Format",
Framework for Internationalized RFC 5322, October 2008.
Email", RFC 6530, February 2012.
[RFC6532] Yang, A., Steele, S., and N. Freed, [RFC5646] Phillips, A. and M. Davis, "Tags for
"Internationalized Email Headers", Identifying Languages", BCP 47, RFC 5646,
RFC 6532, February 2012. September 2009.
[popimap-downgrade] Fujiwara, K., "Post-delivery Message [RFC6530] Klensin, J. and Y. Ko, "Overview and
Downgrading for Internationalized Framework for Internationalized Email",
Email Messages", RFC 6530, February 2012.
draft-ietf-eai-popimap-downgrade-04
(work in progress), October 2011. [RFC6532] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", RFC 6532,
February 2012.
9.2. Informative References 9.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and
POP3 and ACAP", RFC 2595, June 1999. ACAP", RFC 2595, June 1999.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post
Post Office Protocol (POP3) Simple Office Protocol (POP3) Simple Authentication
Authentication and Security Layer and Security Layer (SASL) Authentication
(SASL) Authentication Mechanism", Mechanism", RFC 5034, July 2007.
RFC 5034, July 2007.
[RFC5721] Gellens, R. and C. Newman, "POP3 [RFC5721] Gellens, R. and C. Newman, "POP3 Support for
Support for UTF-8", RFC 5721, UTF-8", RFC 5721, February 2010.
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 the above specification.
Due to interoperability problems with RFC 2047 and limited deployment Due to interoperability problems with RFC 2047 and limited deployment
of RFC 2231, it is hoped these 7-bit encoding mechanisms can be of RFC 2231, it is hoped these 7-bit encoding mechanisms can be
deprecated in the future when UTF-8 header support becomes prevalent. deprecated in the future when UTF-8 header support becomes prevalent.
 End of changes. 53 change blocks. 
166 lines changed or deleted 124 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/