Email Address Internationalizatio J. Yee Internet-Draft Afilias Intended status: Informational July 5, 2009 Expires: January 5, 2010 UTF-8 POP3 Scenarios draft-yee-eai-pop3-scenarios-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 17, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Yee Expires December 17, 2009 [Page 1] Internet-Draft UTF-8 POP3 Scenarios June 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document presents client scenarios in different combinations of Post Office Protocol v3 (POP3) servers and clients (UTF-8, ASCII only). Technical details are also documented, potential as test case reference. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. UTF8POP3 Server and UTF8POP3 Client . . . . . . . . . . . . 3 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . . 3 2.1.2. Retrieving Messages . . . . . . . . . . . . . . . . . . 4 2.2. UTF8POP3 Server and POP3 Client . . . . . . . . . . . . . . 5 2.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Retrieving Messages . . . . . . . . . . . . . . . . . . 5 2.3. POP3 Server and UTF8POP3 Client . . . . . . . . . . . . . . 5 2.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 5 2.3.2. Retrieving Message . . . . . . . . . . . . . . . . . . 6 3. End to End Examples . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Yee Expires December 17, 2009 [Page 2] Internet-Draft UTF-8 POP3 Scenarios June 2009 1. Introduction With the introduction of internationalized email address, there are concerns of compatibility in receiving email messages in current standard Post Office Protocol (POP3) and its new support with UTF8 encoding [I-D.ietf-eai-pop]. This document attempts to describes some scenarios, defines the expected behavior with the protocol sequences if applicable. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. For distinction between current POP3 commands [RFC1939] and proposed POP3 commands [I-D.ietf-eai-pop], "UTF8POP3" refers to both command and environments (server, client) that support the UTF8 encodings. "POP3" refers to ASCII only command and environments. "C:" and "S:" refer to client and server repectively in all protocol exchange sequences in this document. Other terms are inherited from the UTF8SMTP Framework [RFC4952], such as "ascii address" and "non-ascii address" for email address. 1.2. Limitation This document has no intention to describe or define how client presents the message to end user. 2. Scenarios 2.1. UTF8POP3 Server and UTF8POP3 Client 2.1.1. Authentication Once the command 'UTF8' issued from client, the environment operated in UTF8POP3 mode. In authentication state, server will expect to receive non ASCII characters in user name and/or password string. Example 1: C: CAPA S: +OK Capability listing follows: S: UTF8 S: . Yee Expires December 17, 2009 [Page 3] Internet-Draft UTF-8 POP3 Scenarios June 2009 C: UTF8 S: +OK UTF8POP3 enabled C: USER non-ASCII-address S: +OK Hello, non-ASCII-address C: PASS password S: +OK non-ASCII-address has 2 messages (320 octets) Example 2: C: CAPA S: +OK Capability listing follows: S: UTF8 S: . C: UTF8 USER non-ASCII-address S: +OK Hello, non-ASCII-address C: PASS password S: +OK non-ASCII-address has 2 messages (320 octets) Although UTF8POP3 server can process UTF8 encoding, it MUST reject all authentications on user name with non-ASCII characters given that the command 'UTF8' was not issued from client. UTF8POP3 server SHOULD NOT assume client's capability based on non-ascii email address login without issue of command 'UTF8' C: CAPA S: +OK Capability listing follows: S: UTF8 S: . C: USER non-ASCII-address S: -ERR User string contains non ASCII characters 2.1.2. Retrieving Messages UTF8POP3 client, who issued command 'UTF8' and acccepted by server, can accept either UTF8 or ASCII messages. Downgraded messages [RFC5504] would not get up converted by server. UTF8POP3 server MUST give octet count (size) instead of number of characters to response LIST. For example the email address in message is 'Yee Chiu Kit' (in Simplified Chinese). It has 3 characters, but takes 12 octets count (3 octets/bytes each). Message size is 12 + remaining size instead of 3 + remaining size. Simplified sample message: YEECHIUKIT in Simplifed Chinese in UTF8 encoding From: YEECHIUKIT@afilias.info To: Len@afilias.info Yee Expires December 17, 2009 [Page 4] Internet-Draft UTF-8 POP3 Scenarios June 2009 Content-Type: text/plain; charset=UTF-8 Subject: Hello My new email address. The message above has 137 octets (or bytes), YEECHIUKIT takes 12 bytes. Expected protocol sequence (assuming only 1 message in message store, storing the sample message): C: STAT S: +OK 1 137 C: LIST S: +OK 1 message (137 octets) S: . C: RETR 1 S: +OK 137 octets S: S: . 2.2. UTF8POP3 Server and POP3 Client 2.2.1. Authentication Because the command 'UTF8' was never issued from client, the whole environment MUST operate under POP3 behavior defined in [RFC1939]. 2.2.2. Retrieving Messages Server MUST down convert any message from native UTF8 message to Internet Message Format [RFC5322]. As suggested in [I-D.ietf-eai-pop], downgrade mechanism described from [RFC5504] is not the required mechanism, but highly recommended. 2.3. POP3 Server and UTF8POP3 Client 2.3.1. Authentication UTF8POP3 client SHOULD check server's capability with command CAPA to confirm if server supported UTF8POP3 (command UTF8). If not, client MAY notify end user about server not supporting UTF8POP3, and MAY either 1. stop attempting to authenticate, or 2. attempt to authenticate in only POP3 environment Authentication to continue after command UTF8 failed: Yee Expires December 17, 2009 [Page 5] Internet-Draft UTF-8 POP3 Scenarios June 2009 C: CAPA S" +OK Capability listing follow: S: LANG S: TOP S: . C: UTF8 USER ASCII-address S: -ERR Unknown command: UTF8 C: USER ASCII-address S: ... 2.3.2. Retrieving Message The client should expect to receive ASCII only messages. There maybe downgraded messages, and it is up to client to make any conversion or not. 3. End to End Examples Sample message 1 (UTF8 message, 137 octets): From: YEECHIUKIT@afilias.info To: Len@afilias.info Content-Type: text/plain; charset=UTF-8 Subject: Hello My new email address. Sample message 2 (ASCII message, downgraded, assuming 500 octets): Downgraded-From: =?UTF-8?Q?>?= From: jyee@afilias.info To: Len@afilias.info Subject: downgrade message Chiu-Kit does not translate to Joseph, and vice versa. End to End Example 1 (UTF8POP3 server, UTF8POP3 client, 1 successful login with email retrieval, 1 fail login): S: < wait for connection on TCP port 110 > C: < open connection > S: +OK POP3 server ready C: CAPA S: +OK Capability listing follows: S: UTF8 S: . C: UTF8 Yee Expires December 17, 2009 [Page 6] Internet-Draft UTF-8 POP3 Scenarios June 2009 S: +OK UTF8POP3 enabled C: USER non-asccii-address S: Hello non-ascii-address C: PASS password S: +OK non-ascii-address has 2 messages (637 octets) C: STAT S: +OK 2 637 C: LIST S: +OK 2 messages (637 octets) S: 1 137 S: 2 500 S: . C: RETR 1 S: +OK 137 octets S: S: . C: QUIT S: +OK POP3 server signing off C: S: C: S: +OK POP3 server ready C: USER non-ascii-address S: -ERR User name contains non ASCII characters C: QUIT S: +OK POP3 server signing off C: S: 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations None. 6. References 6.1. Normative References [I-D.ietf-eai-pop] Newman, C. and R. Gellens, "POP3 Support for UTF-8", draft-ietf-eai-pop-05 (work in progress), November 2008. Yee Expires December 17, 2009 [Page 7] Internet-Draft UTF-8 POP3 Scenarios June 2009 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. 6.2. Informative References [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009. Author's Address Joseph Yee Afilias Suite 204, 4141 Yonge Street Toronto, Ontario M2P 2A8 Canada Phone: +1 416 673 4196 Email: jyee@afilias.info Yee Expires December 17, 2009 [Page 8]