draft-ietf-eai-rfc5721bis-01.txt   draft-ietf-eai-rfc5721bis-02.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
Updates: RFC1939 (if approved) Oracle Intended status: Standards Track Oracle
Intended status: Standards Track J. Yao Expires: January 12, 2012 J. Yao
Expires: October 1, 2011 CNNIC CNNIC
K. Fujiwara K. Fujiwara
JPRS JPRS
March 30, 2011 July 11, 2011
POP3 Support for UTF-8 POP3 Support for UTF-8
draft-ietf-eai-rfc5721bis-01.txt draft-ietf-eai-rfc5721bis-02.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 error strings. 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 October 1, 2011. This Internet-Draft will expire on January 12, 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 35 skipping to change at page 2, line 35
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10 7.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 10
7.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10 7.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 10
7.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
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, and mail drops that are accessed using POP3
[RFC1939] might natively store UTF-8. [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,
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 outside the ASCII character set, and a mechanism names and passwords with UTF-8 charset beyond ASCII, and a mechanism
to support UTF-8 protocol-level error strings in a language to support UTF-8 charset in protocol level response strings for
appropriate for the user. languages beyond English.
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].
skipping to change at page 4, line 27 skipping to change at page 4, line 27
Added Commands: Added Commands:
LANG LANG
Standard commands affected: Standard commands affected:
All All
Announced states / possible differences: Announced states / possible differences:
both / no both / no
Commands valid in states: Commands valid in states:
AUTHENTICATION, TRANSACTION AUTHORIZATION, TRANSACTION
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
skipping to change at page 7, line 20 skipping to change at page 7, line 20
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. switches the session from ASCII to UTF-8 mode. In UTF-8 mode, it
means that both servers and clients can send and accept the 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 [I-D.ietf-eai-rfc5335bis] and/or 8bit
skipping to change at page 7, line 47 skipping to change at page 7, line 49
Internet Mail Format without UTF-8 mode support. Internet Mail Format without UTF-8 mode support.
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 are. 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. The
down-converted message may be larger. The server may choose various down-converted message may be larger. The server may choose various
strategies regarding down-conversion, which include when to down- strategies regarding down-conversion, which include when to down-
convert, whether to cache or store the down-converted form of a convert, whether to cache or store the down-converted form of a
message (and if so, for how long), and whether to calculate or retain message (and if so, for how long), and whether to calculate or retain
the size of a down-converted message independently of the down- the size of a down-converted message independently of the down-
skipping to change at page 9, line 5 skipping to change at page 9, line 7
and PASS commands. 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 user names
or passwords MUST apply SASLprep [RFC4013] to the user name and or passwords MUST apply SASLprep [RFC4013] to the user name and
password used to compute the APOP digest. password used to compute the APOP digest.
When applying SASLprep [RFC4013], servers MUST reject UTF-8 user When applying SASLprep [RFC4013], servers MUST reject UTF-8 user
names or passwords that contain a Unicode character listed in Section names or passwords that contain a Unicode character listed in Section
2.3 of SASLprep [RFC4013]. When applying SASLprep to the USER 2.3 of SASLprep [RFC4013]. When applying SASLprep to the USER
argument, the PASS argument, or the APOP username argument, a argument, the PASS argument, or the APOP username argument, a
compliant server or client MUST treat them as a query string (i.e., compliant server or client MUST treat them as a query string
unassigned Unicode code points are allowed). When applying SASLprep [RFC3454](i.e., unassigned Unicode code points are allowed). When
to the APOP password argument, a compliant server or client MUST applying SASLprep to the APOP password argument, a compliant server
treat them as a stored string (i.e., unassigned Unicode code points or client MUST treat them as a stored string [RFC3454] (i.e.,
are prohibited). unassigned Unicode code points are prohibited).
The client does not need to issue the UTF8 command prior to using The client does not need to issue the UTF8 command prior to using
UTF-8 in authentication. However, clients MUST NOT use UTF-8 UTF-8 in authentication. However, clients MUST NOT use UTF-8
characters in USER, PASS, or APOP commands unless the USER argument characters in USER, PASS, or APOP commands unless the USER argument
is included in the UTF8 capability response. is included in the UTF8 capability response.
The server MUST reject UTF-8 user names or passwords that fail to The server MUST reject UTF-8 user names 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 characters in the AUTH command is governed by the POP3 Use of UTF-8 characters in the AUTH command is governed by the POP3
skipping to change at page 10, line 25 skipping to change at page 10, line 27
7. Change History 7. Change History
7.1. draft-ietf-eai-rfc5721bis: Version 00 7.1. draft-ietf-eai-rfc5721bis: Version 00
following the new charter following the new charter
7.2. draft-ietf-eai-rfc5721bis: Version 01 7.2. draft-ietf-eai-rfc5721bis: Version 01
refine the texts refine the texts
7.3. draft-ietf-eai-rfc5721bis: Version 02
update the texts based on Joseph's comments
8. References 8. References
8.1. Normative References 8.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-10 (work
in progress), September 2010. in progress), September 2010.
[I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", "Internationalized Email Headers",
draft-ietf-eai-rfc5335bis-10 (work in draft-ietf-eai-rfc5335bis-11 (work in
progress), March 2011. progress), July 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 11, line 18 skipping to change at page 11, line 25
BCP 14, RFC 2119, March 1997. BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on [RFC2277] Alvestrand, H., "IETF Policy on
Character Sets and Languages", BCP 18, Character Sets and Languages", BCP 18,
RFC 2277, January 1998. RFC 2277, January 1998.
[RFC2449] Gellens, R., Newman, C., and L. [RFC2449] Gellens, R., Newman, C., and L.
Lundblade, "POP3 Extension Mechanism", Lundblade, "POP3 Extension Mechanism",
RFC 2449, November 1998. RFC 2449, November 1998.
[RFC3454] Hoffman, P. and M. Blanchet,
"Preparation of Internationalized
Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, format of ISO 10646", STD 63,
RFC 3629, November 2003. RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep [RFC4013] Zeilenga, K., "SASLprep: Stringprep
Profile for User Names and Passwords", Profile for User Names and Passwords",
RFC 4013, February 2005. RFC 4013, February 2005.
[RFC4647] Phillips, A. and M. Davis, "Matching [RFC4647] Phillips, A. and M. Davis, "Matching
of Language Tags", BCP 47, RFC 4647, of Language Tags", BCP 47, RFC 4647,
skipping to change at page 12, line 19 skipping to change at page 12, line 35
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.
While it is possible to provide useful examples for language
negotiation without support for non-ASCII characters, it is difficult
to provide useful examples for commands specifically designed to use
the UTF-8 charset un-encoded when the document format is limited to
ASCII. As a result, there are no plans to provide examples for that
part of the specification as long as this remains an experimental
proposal. However, implementers of this specification are encouraged
to provide examples to the document authors for a future revision.
Appendix B. Acknowledgments Appendix B. Acknowledgments
Thanks to John Klensin, Tony Hansen, and other EAI working group Thanks to John Klensin, Tony Hansen, and other EAI working group
participants who provided helpful suggestions and interesting debate participants who provided helpful suggestions and interesting debate
that improved this specification. that improved this specification.
Authors' Addresses Authors' Addresses
Randall Gellens Randall Gellens
QUALCOMM Incorporated QUALCOMM Incorporated
 End of changes. 17 change blocks. 
31 lines changed or deleted 34 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/