draft-ietf-eai-rfc5721bis-03.txt   draft-ietf-eai-rfc5721bis-04.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: 5721 (if approved) C. Newman
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: May 19, 2012 J. Yao Expires: October 12, 2012 J. Yao
CNNIC CNNIC
K. Fujiwara K. Fujiwara
JPRS JPRS
November 16, 2011 April 10, 2012
POP3 Support for UTF-8 POP3 Support for UTF-8
draft-ietf-eai-rfc5721bis-03.txt draft-ietf-eai-rfc5721bis-04.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. This specification replaces RFC 5721. textual strings.
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 May 19, 2012. This Internet-Draft will expire on October 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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 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 . . . . . . . . . . . . . 8 3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 9
4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9 4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9
5. UTF-8 Response Code . . . . . . . . . . . . . . . . . . . . . 9 5. UTF-8 Response Code . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 11 8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 11
8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 11 8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 11
8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11 8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11
8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11 8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11
8.5. draft-ietf-eai-rfc5721bis: Version 04 . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
9.3. 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
(EAI) protocols described in the EAI Framework document (EAI) protocols described in the EAI Framework document [RFC6530].
[I-D.ietf-eai-frmwrk-4952bis]. As part of the overall EAI work, As part of the overall EAI work, email messages may be transmitted
email messages may be transmitted and delivered containing un-encoded and delivered containing un-encoded UTF-8 characters in the header
UTF-8 characters in the header and/or body, and mail drops that are and/or body, and mail drops that are accessed using POP3 [RFC1939]
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" as described in "Internationalized Email Headers" [RFC6532]. It also
[I-D.ietf-eai-rfc5335bis]. It also adds a mechanism to support login adds a mechanism to support login names and passwords containing
names and passwords containing UTF-8 characters, and a mechanism to UTF-8 characters, and a mechanism to support UTF-8 characters in
support UTF-8 characters in protocol level response strings as well protocol level response strings as well as the ability to negotiate a
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 down-convert.
Within this specification, the term "down-conversion" refers to the Within this specification, the term "down-convert" refers to the
process of modifying a message containing UTF-8 headers process of modifying a message containing UTF-8 headers [RFC6532] or
[I-D.ietf-eai-rfc5335bis] or body parts with 8bit content-transfer- body parts with 8bit content-transfer-encoding, as defined in MIME
encoding, as defined in MIME Section 2.8 [RFC2045], into conforming Section 2.8 [RFC2045], into conforming 7-bit Internet Message Format
7-bit Internet Message Format [RFC5322] with message header [RFC5322] with message header extensions for non-ASCII text [RFC2047]
extensions for non-ASCII text [RFC2047] and other 7-bit encodings. and other 7-bit encodings. The method of down-convert is specified
Down-conversion is specified by "Post-delivery Message Downgrading by "Post-delivery Message Downgrading for Internationalized Email
for Internationalized Email Messages" [popimap-downgrade]. 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 same problem RFC 5721 [RFC5721]. Section 6 of [RFC6530] describes
[I-D.ietf-eai-frmwrk-4952bis] describes the changes in approach the changes in approach between RFC 5721 [RFC5721] and this
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
skipping to change at page 7, line 37 skipping to change at page 7, line 40
servers and clients can send and accept UTF-8 characters. servers and clients can send and accept UTF-8 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 [RFC6532] and/or 8bit content-transfer-
content-transfer-encoding, as defined in MIME Section 2.8 [RFC2045]. encoding, as defined in MIME Section 2.8 [RFC2045]. In UTF-8 mode,
In UTF-8 mode, both UTF-8 and ASCII messages are sent to the client both UTF-8 and ASCII messages are sent to the client as-is (without
as-is (without conversion). When not in UTF-8 mode, UTF-8 messages conversion). When not in UTF-8 mode, UTF-8 messages in a native
in a native UTF-8 maildrop MUST NOT be sent to the client as-is. If UTF-8 maildrop MUST NOT be sent to the client as-is. If a client
a client requests a UTF-8 message when not in UTF-8 mode, the server requests a UTF-8 message when not in UTF-8 mode, the server MUST
MUST either down-convert (downgrade) the message content it sends to either down-convert (downgrade) the message content it sends to the
the client to comply with unextended POP and Internet Mail Format client to comply with unextended POP and Internet Mail Format without
without UTF-8 mode support, or fail the request with a -ERR response UTF-8 mode support, or fail the request with a -ERR response
containing the UTF-8 response code (see section 5). The UTF8 command containing the UTF-8 response code (see section 5). The UTF8 command
MAY fail. 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 or command, in which case the server MAY choose to down-convert it or
reject the command which requested the message with the new UTF-8 reject the command which requested the message with the new UTF-8
response code (see Section 5). The down-converted message may be response code (see Section 5). The down-converted message may be
larger. The server may choose various strategies regarding down- larger. The server may choose various strategies regarding down-
conversion, which include when to down-convert, whether to cache or convert, which include when to down-convert, whether to cache or
store the down-converted form of a message (and if so, for how long), store the down-converted form of a message (and if so, for how long),
and whether to calculate or retain the size of a down-converted and whether to calculate or retain the size of a down-converted
message independently of the down-converted content. If the server message independently of the down-converted content. If the server
does not have immediate access to the accurate down-converted size, does not have immediate access to the accurate down-converted size,
it may be faster to estimate rather than calculate it. Servers are it may be faster to estimate rather than calculate it. Servers are
expected to normally follow the RFC 1939 [RFC1939] text on using the expected to normally follow the RFC 1939 [RFC1939] text on using the
"exact size" in a scan listing, but there may be situations with "exact size" in a scan listing, but there may be situations with
maildrops containing very large numbers of messages in which this maildrops containing very large numbers of messages in which this
might be a problem. If the server does estimate, reporting a scan 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 listing size smaller than what it turns out to be could be a problem
skipping to change at page 9, line 40 skipping to change at page 9, line 45
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. Mechanisms for 7-bit downgrading to help comply
with the standards are described in [popimap-downgrade]. with the standards are described in [popimap-downgrade] and
[I-D.ietf-eai-simpledowngrade]. The implementors MAY choose one of
them to implement downgrade.
5. UTF-8 Response Code 5. UTF-8 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: UTF-8, described below.
Complete response code: Complete response code:
UTF8 UTF8
Valid for responses: Valid for responses:
skipping to change at page 10, line 22 skipping to change at page 10, line 25
The UTF-8 response code indicates that a failure is due to a request 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 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 (or wait
for the server to be in a better mood and willing to downconvert). for the server to be in a better mood and willing to downconvert).
6. IANA Considerations 6. IANA Considerations
This specification updates two capabilities ("UTF8" and "LANG") to The section 2 and 3 of this specification update two capabilities
the POP3 capability registry [RFC2449]. ("UTF8" and "LANG") to the POP3 capability registry [RFC2449].
This specification also adds one new response code ("UTF-8") to the The section 5 of this specification also adds one new response code
POP3 response codes registry [RFC2449]. ("UTF-8") 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
skipping to change at page 11, line 29 skipping to change at page 11, line 33
update the texts based on Joseph's comments update the texts based on Joseph's comments
8.4. draft-ietf-eai-rfc5721bis: Version 03 8.4. draft-ietf-eai-rfc5721bis: Version 03
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
improve the texts
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and [I-D.ietf-eai-simpledowngrade] Gulbrandsen, A., "EAI: Simplified
Framework for Internationalized POP/IMAP downgrading",
Email", draft-ietf-eai-simpledowngrade-03
draft-ietf-eai-frmwrk-4952bis-12 (work (work in progress), March 2012.
in progress), October 2011.
[I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, [RFC1939] Myers, J. and M. Rose, "Post Office
"Internationalized Email Headers", Protocol - Version 3", STD 53,
draft-ietf-eai-rfc5335bis-13 (work in RFC 1939, May 1996.
progress), October 2011.
[RFC1939] Myers, J. and M. Rose, "Post Office [RFC2045] Freed, N. and N. Borenstein,
Protocol - Version 3", STD 53, "Multipurpose Internet Mail
RFC 1939, May 1996. Extensions (MIME) Part One: Format of
Internet Message Bodies", RFC 2045,
November 1996.
[RFC2045] Freed, N. and N. Borenstein, [RFC2047] Moore, K., "MIME (Multipurpose
"Multipurpose Internet Mail Extensions Internet Mail Extensions) Part Three:
(MIME) Part One: Format of Internet Message Header Extensions for Non-
Message Bodies", RFC 2045, ASCII Text", RFC 2047, November 1996.
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose [RFC2119] Bradner, S., "Key words for use in
Internet Mail Extensions) Part Three: RFCs to Indicate Requirement Levels",
Message Header Extensions for Non- BCP 14, RFC 2119, March 1997.
ASCII Text", RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in [RFC2277] Alvestrand, H., "IETF Policy on
RFCs to Indicate Requirement Levels", Character Sets and Languages",
BCP 14, RFC 2119, March 1997. BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand, H., "IETF Policy on [RFC2449] Gellens, R., Newman, C., and L.
Character Sets and Languages", BCP 18, Lundblade, "POP3 Extension
RFC 2277, January 1998. Mechanism", RFC 2449, November 1998.
[RFC2449] Gellens, R., Newman, C., and L. [RFC3454] Hoffman, P. and M. Blanchet,
Lundblade, "POP3 Extension Mechanism", "Preparation of Internationalized
RFC 2449, November 1998. Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3454] Hoffman, P. and M. Blanchet, [RFC3629] Yergeau, F., "UTF-8, a transformation
"Preparation of Internationalized format of ISO 10646", STD 63,
Strings ("stringprep")", RFC 3454, RFC 3629, November 2003.
December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC4013] Zeilenga, K., "SASLprep: Stringprep
format of ISO 10646", STD 63, Profile for User Names and
RFC 3629, November 2003. Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep [RFC4647] Phillips, A. and M. Davis, "Matching
Profile for User Names and Passwords", of Language Tags", BCP 47, RFC 4647,
RFC 4013, February 2005. September 2006.
[RFC4647] Phillips, A. and M. Davis, "Matching [RFC5322] Resnick, P., Ed., "Internet Message
of Language Tags", BCP 47, RFC 4647, Format", RFC 5322, October 2008.
September 2006.
[RFC5322] Resnick, P., Ed., "Internet Message [RFC5646] Phillips, A. and M. Davis, "Tags for
Format", RFC 5322, October 2008. Identifying Languages", BCP 47,
RFC 5646, September 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for [RFC6530] Klensin, J. and Y. Ko, "Overview and
Identifying Languages", BCP 47, Framework for Internationalized
RFC 5646, September 2009. Email", RFC 6530, February 2012.
9.2. Informative References [RFC6532] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers",
RFC 6532, February 2012.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 [popimap-downgrade] Fujiwara, K., "Post-delivery Message
and ACAP", RFC 2595, June 1999. Downgrading for Internationalized
Email Messages",
draft-ietf-eai-popimap-downgrade-04
(work in progress), October 2011.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The 9.2. Informative References
Post Office Protocol (POP3) Simple
Authentication and Security Layer
(SASL) Authentication Mechanism",
RFC 5034, July 2007.
[popimap-downgrade] Fujiwara, K., "Post-delivery Message [RFC2595] Newman, C., "Using TLS with IMAP,
Downgrading for Internationalized POP3 and ACAP", RFC 2595, June 1999.
Email Messages",
draft-ietf-eai-popimap-downgrade-00
(work in progress), October 2010.
9.3. Informative References [RFC5034] Siemborski, R. and A. Menon-Sen, "The
Post Office Protocol (POP3) Simple
Authentication and Security Layer
(SASL) Authentication Mechanism",
RFC 5034, July 2007.
[RFC5721] Gellens, R. and C. Newman, "POP3 [RFC5721] Gellens, R. and C. Newman, "POP3
Support for UTF-8", RFC 5721, Support for 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.
USER is optional because the implementation burden of SASLprep USER is optional because the implementation burden of SASLprep
[RFC4013] is not well understood, and mandating such support in all [RFC4013] is not well understood, and mandating such support in all
cases could negatively impact deployment. cases could negatively impact deployment.
Appendix B. Acknowledgments Appendix B. Acknowledgments
Thanks to John Klensin, Tony Hansen, and other EAI working group Thanks to John Klensin, Joseph Yee, Tony Hansen, Alexey Melnikov and
participants who provided helpful suggestions and interesting debate other EAI working group participants who provided helpful suggestions
that improved this specification. and interesting debate that improved 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 US
EMail: rg+ietf@qualcomm.com EMail: rg+ietf@qualcomm.com
 End of changes. 41 change blocks. 
114 lines changed or deleted 121 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/