draft-ietf-eai-rfc5721bis-02.txt   draft-ietf-eai-rfc5721bis-03.txt 
Network Working Group R. Gellens Network Working Group R. Gellens
Internet-Draft QUALCOMM Incorporated Internet-Draft QUALCOMM Incorporated
Obsoletes: RFC5721 (if approved) C. Newman Obsoletes: RFC5721 (if approved) C. Newman
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: January 12, 2012 J. Yao Expires: May 19, 2012 J. Yao
CNNIC CNNIC
K. Fujiwara K. Fujiwara
JPRS JPRS
July 11, 2011 November 16, 2011
POP3 Support for UTF-8 POP3 Support for UTF-8
draft-ietf-eai-rfc5721bis-02.txt draft-ietf-eai-rfc5721bis-03.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. This specification replaces RFC 5721.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 12, 2012. This Internet-Draft will expire on May 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . 8 3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 8
4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9 4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. UTF-8 Response Code . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10 8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 11
7.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 10 8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
9.3. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 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 (EAI) protocols described in the EAI Framework document
[I-D.ietf-eai-frmwrk-4952bis]. As part of the overall EAI work, [I-D.ietf-eai-frmwrk-4952bis]. As part of the overall EAI work,
email messages may be transmitted and delivered containing un-encoded email messages may be transmitted and delivered containing un-encoded
UTF-8 characters, and mail drops that are accessed using POP3 UTF-8 characters in the header and/or body, and mail drops that are
[RFC1939] might natively store UTF-8. accessed using POP3 [RFC1939] 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)
as described in "Internationalized Email Headers" as described in "Internationalized Email Headers"
[I-D.ietf-eai-rfc5335bis]. It also adds a mechanism to support login [I-D.ietf-eai-rfc5335bis]. It also adds a mechanism to support login
names and passwords with UTF-8 charset beyond ASCII, and a mechanism names and passwords containing UTF-8 characters, and a mechanism to
to support UTF-8 charset in protocol level response strings for support UTF-8 characters in protocol level response strings as well
languages beyond English. as the ability to negotiate a language for such response strings.
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
server is unwilling to down-convert.
Within this specification, the term "down-conversion" refers to the Within this specification, the term "down-conversion" refers to the
process of modifying a message containing UTF-8 headers process of modifying a message containing UTF-8 headers
[I-D.ietf-eai-rfc5335bis] or body parts with 8bit content-transfer- [I-D.ietf-eai-rfc5335bis] or body parts with 8bit content-transfer-
encoding, as defined in MIME Section 2.8 [RFC2045], into conforming encoding, as defined in MIME Section 2.8 [RFC2045], into conforming
7-bit Internet Message Format [RFC5322] with message header 7-bit Internet Message Format [RFC5322] with message header
extensions for non-ASCII text [RFC2047] and other 7-bit encodings. extensions for non-ASCII text [RFC2047] and other 7-bit encodings.
Down-conversion is specified by "Post-delivery Message Downgrading Down-conversion is specified by "Post-delivery Message Downgrading
for Internationalized Email Messages" [popimap-downgrade]. for Internationalized Email Messages" [popimap-downgrade].
This specification replaces an earlier, experimental, approach to the
same problem RFC 5721 [RFC5721]. Section 6 of
[I-D.ietf-eai-frmwrk-4952bis] describes the changes in approach
between RFC 5721 [RFC5721] and this 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
skipping to change at page 4, line 38 skipping to change at page 4, line 42
Specification reference: Specification reference:
this document this document
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 should use when sending human- negotiate which language the server uses when sending human-readable
readable text. text.
A server that advertises the LANG extension MUST use the language A server that advertises the LANG extension MUST use the language
"i-default" as described in [RFC2277] as its default language until "i-default" as described in [RFC2277] as its default language until
another supported language is negotiated by the client. A server another supported language is negotiated by the client. A server
MUST include "i-default" as one of its supported languages. 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
skipping to change at page 7, line 20 skipping to change at page 7, line 26
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 ASCII to UTF-8 mode. In UTF-8 mode, it switches the session from ASCII to UTF-8 mode. In UTF-8 mode, both
means that both servers and clients can send and accept the UTF-8 servers and clients can send and accept UTF-8 characters.
characters.
3.1. The UTF8 Command 3.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.
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 [I-D.ietf-eai-rfc5335bis] and/or 8bit internationalized headers [I-D.ietf-eai-rfc5335bis] and/or 8bit
content-transfer-encoding, as defined in MIME Section 2.8 [RFC2045]. 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 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 as-is (without 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. The in a native UTF-8 maildrop MUST NOT be sent to the client as-is. If
UTF8 Commands MAY fail. UTF-8 messages in a native UTF-8 maildrop a client requests a UTF-8 message when not in UTF-8 mode, the server
MAY be down-converted (downgraded) to comply with unextended POP and MUST either down-convert (downgrade) the message content it sends to
Internet Mail Format without UTF-8 mode support. the client to comply with unextended POP and Internet Mail Format
without UTF-8 mode support, or fail the request with a -ERR response
containing the UTF-8 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. 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 Mail stores are either ASCII or native UTF-8, and clients either
issue the UTF8 command or not. The message needs converting only issue the UTF8 command or not. The message needs converting only
when it is native UTF-8 and the client has not issued the UTF8 when it is native UTF-8 and the client has not issued the UTF8
command, in which case the server MAY choose to down-convert it. The command, in which case the server MAY choose to down-convert it or
down-converted message may be larger. The server may choose various reject the command which requested the message with the new UTF-8
strategies regarding down-conversion, which include when to down- response code (see Section 5). The down-converted message may be
convert, whether to cache or store the down-converted form of a larger. The server may choose various strategies regarding down-
message (and if so, for how long), and whether to calculate or retain conversion, which include when to down-convert, whether to cache or
the size of a down-converted message independently of the down- store the down-converted form of a message (and if so, for how long),
converted content. If the server does not have immediate access to and whether to calculate or retain the size of a down-converted
the accurate down-converted size, it may be faster to estimate rather message independently of the down-converted content. If the server
than calculate it. Servers are expected to normally follow the RFC does not have immediate access to the accurate down-converted size,
1939 [RFC1939] text on using the "exact size" in a scan listing, but it may be faster to estimate rather than calculate it. Servers are
there may be situations with maildrops containing very large numbers expected to normally follow the RFC 1939 [RFC1939] text on using the
of messages in which this might be a problem. If the server does "exact size" in a scan listing, but there may be situations with
estimate, reporting a scan listing size smaller than what it turns maildrops containing very large numbers of messages in which this
out to be could be a problem for some clients. In summary, it is might be a problem. If the server does estimate, reporting a scan
better for servers to report accurate sizes, but if this is not listing size smaller than what it turns out to be could be a problem
possible, high guesses are better than small ones. Some POP servers for some clients. In summary, it is better for servers to report
include the message size in the non-standardized text response accurate sizes, but if this is not possible, high guesses are better
following "+OK" (the 'text' production of RFC 2449 [RFC2449]), in a than small ones. Some POP servers include the message size in the
RETR or TOP response (possibly because some examples in POP3 non-standardized text response following "+OK" (the 'text' production
[RFC1939] do so). There has been at least one known case of a client of RFC 2449 [RFC2449]), in a RETR or TOP response (possibly because
relying on this to know when it had received all of the message some examples in POP3 [RFC1939] do so). There has been at least one
rather than following the POP3 [RFC1939] rule of looking for a line known case of a client relying on this to know when it had received
consisting of a termination octet (".") and a CRLF pair. While any all of the message rather than following the POP3 [RFC1939] rule of
such client is non-compliant, if a server does include the size in looking for a line consisting of a termination octet (".") and a CRLF
such text, it is better if it is accurate. 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 32 skipping to change at page 9, line 42
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. Mechanisms for 7-bit downgrading to help comply
with the standards are described in [popimap-downgrade]. with the standards are described in [popimap-downgrade].
5. IANA Considerations 5. UTF-8 Response Code
Per "POP3 Extension Mechanism" [RFC2449], this document adds a new
response code: UTF-8, described below.
Complete response code:
UTF8
Valid for responses:
-ERR
Valid for commands:
LIST, TOP, RETR
Response code meaning and expected client behavior:
The UTF-8 response code indicates that a failure is due to a request
when not in UTF-8 mode for message content containing UTF-8
characters.
The client MAY reissue the command after entering UTF-8 mode (or wait
for the server to be in a better mood and willing to downconvert).
6. IANA Considerations
This specification updates two capabilities ("UTF8" and "LANG") to This specification updates two capabilities ("UTF8" and "LANG") to
the POP3 capability registry [RFC2449]. the POP3 capability registry [RFC2449].
6. Security Considerations This specification also adds one new response code ("UTF-8") to the
POP3 response codes registry [RFC2449].
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 MUST
implement a configuration to prevent this exposure. implement a configuration to prevent this exposure.
skipping to change at page 10, line 17 skipping to change at page 11, line 7
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 The UTF8 command description (Section 3.1) contains a discussion on
reporting inaccurate sizes. An additional risk to doing so is that, reporting inaccurate sizes. An additional risk to doing so is that,
if a client allocates buffers based on the reported size, it may if a client allocates buffers based on the reported size, it may
overrun the buffer, crash, or have other problems if the message data overrun the buffer, crash, or have other problems if the message data
is larger than reported. is larger than reported.
7. Change History 8. Change History
7.1. draft-ietf-eai-rfc5721bis: Version 00 8.1. draft-ietf-eai-rfc5721bis: Version 00
following the new charter following the new charter
7.2. draft-ietf-eai-rfc5721bis: Version 01 8.2. draft-ietf-eai-rfc5721bis: Version 01
refine the texts refine the texts
7.3. draft-ietf-eai-rfc5721bis: Version 02 8.3. draft-ietf-eai-rfc5721bis: Version 02
update the texts based on Joseph's comments update the texts based on Joseph's comments
8. References 8.4. draft-ietf-eai-rfc5721bis: Version 03
8.1. Normative References improve the texts
text instructing servers to either downconvert or reject
new UTF-8 response code for use
9. References
9.1. Normative References
[I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and
Framework for Internationalized Framework for Internationalized
Email", Email",
draft-ietf-eai-frmwrk-4952bis-10 (work draft-ietf-eai-frmwrk-4952bis-12 (work
in progress), September 2010. in progress), October 2011.
[I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", "Internationalized Email Headers",
draft-ietf-eai-rfc5335bis-11 (work in draft-ietf-eai-rfc5335bis-13 (work in
progress), July 2011. progress), October 2011.
[RFC1939] Myers, J. and M. Rose, "Post Office [RFC1939] Myers, J. and M. Rose, "Post Office
Protocol - Version 3", STD 53, Protocol - Version 3", STD 53,
RFC 1939, May 1996. RFC 1939, May 1996.
[RFC2045] Freed, N. and N. Borenstein, [RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, Message Bodies", RFC 2045,
November 1996. November 1996.
skipping to change at page 12, line 5 skipping to change at page 12, line 47
of Language Tags", BCP 47, RFC 4647, of Language Tags", BCP 47, RFC 4647,
September 2006. September 2006.
[RFC5322] Resnick, P., Ed., "Internet Message [RFC5322] Resnick, P., Ed., "Internet Message
Format", RFC 5322, October 2008. Format", RFC 5322, October 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for [RFC5646] Phillips, A. and M. Davis, "Tags for
Identifying Languages", BCP 47, Identifying Languages", BCP 47,
RFC 5646, September 2009. RFC 5646, September 2009.
8.2. Informative References 9.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 [RFC2595] Newman, C., "Using TLS with IMAP, POP3
and ACAP", RFC 2595, June 1999. and ACAP", RFC 2595, June 1999.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The [RFC5034] Siemborski, R. and A. Menon-Sen, "The
Post Office Protocol (POP3) Simple Post Office Protocol (POP3) Simple
Authentication and Security Layer Authentication and Security Layer
(SASL) Authentication Mechanism", (SASL) Authentication Mechanism",
RFC 5034, July 2007. RFC 5034, July 2007.
[popimap-downgrade] Fujiwara, K., "Post-delivery Message [popimap-downgrade] Fujiwara, K., "Post-delivery Message
Downgrading for Internationalized Downgrading for Internationalized
Email Messages", Email Messages",
draft-ietf-eai-popimap-downgrade-00 draft-ietf-eai-popimap-downgrade-00
(work in progress), October 2010. (work in progress), October 2010.
9.3. Informative References
[RFC5721] Gellens, R. and C. Newman, "POP3
Support for UTF-8", 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 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.
USER is optional because the implementation burden of SASLprep USER is optional because the implementation burden of SASLprep
 End of changes. 26 change blocks. 
68 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/