Internet Draft                                 Jiankang Yao,  Editor
                  Draft-Lee-JET-IMA-00.txt                                 CNNIC
                  June 27, 2005                                    Jeff Yeh    Editor
                  Expires: December 27,2005                                TWNIC
               
               
                                   Internationalized eMail Address (IMA)
                                       < draft-lee-jet-ima-00.txt >
               
               
               Status of this Memo
               
                  By submitting this Internet-Draft, each author represents that any
                  applicable patent or other IPR claims of which he or she is aware
                  have been or will be disclosed, and any of which he or she becomes
                  aware will be disclosed, in accordance with Section 6 of BCP 79.
               
                  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/1id-abstracts.html
               
                  The list of Internet-Draft Shadow Directories can be accessed at
                  http://www.ietf.org/shadow.html
               
                  This Internet-Draft expires on December 27, 2005.
               
               
               
                  Abstract
               
                  An email address has two parts - local part and domain part -
                  separated by "@" sign. This document describes a basic solution to
                  internationalized email address (IMA) and includes some preliminary
                  survey results. The proposed solution enables SMTP servers to support
                  IMA. The solution discussed in this document is immediately
                  deployable by interested parties without affecting or breaking any
                  other existing systems.
               
                  Document Conventions
               
               
               
               JET                    Expires - December 2005               [Page 1]


               Internet draft                   IMA                        June 2005
               
               
               
                   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 RFC 2119 [RFC2119].
               
               1. Introduction to IMA
               
                  In order to use internationalized email addresses, we need to
                  internationalize both domain part and local part of email address.
                  Domain part of email addresses had been internationalized through
                  IDNA [RFC3490]. But the local part of email address still remains as
                  non internationalized.
               
                  At present, the use of Internet email address is restricted to a
                  subset of 7-bit ASCII [RFC2821][RFC2822]. The MIME extensions
                  provides a mechanism for the transmission of non-ASCII data that were
                  previously unsupported in Internet mail. But it does not provide the
                  mechanism for internationalized email address. [RFC2047] defines the
                  message header extension for non ASCII 8-bit MIME messages. However,
                  it does not address the issue if email addresses include non-ASCII
                  characters. Anticipating the need to use the internationalized email
                  address, the SMTP protocol should be extended to provide the
                  transport mechanism for the internationalized email address. The
                  length restrict to the local part in the section of RFC 2822 may need
                  to be updated.
               
               2. Problem statement
               
                  Internationalized Domain Name (IDN) was standardized 2 years ago
                  (2003) and several registries started to accept IDN registrations and
                  the name resolutions. While the take-up of IDN varies, there is a
                  strong demand for IDN in the regions where English is not their
                  native language.
               
                  Particularly in the CJK community, we noticed that registrants of IDN
                  often enquired about if they could use Internationalized eMail
                  Address (IMA) too. Unfortunately, while the domain name portion of
                  the Email address could use IDN standards, there are no standards to
                  internationalize the local-part (left hand side of the "@" mark).
               
                  On the other hand, we envisage strong demands for IMA when IDN
                  becomes popular. IMA will also promote the deployment of IDN.
               
                  Several solutions for IMA have been deployed, e.g.,in China (35.com,
                  zzy.cn, bizcn.com, ce.net.cn, dns.com.cn and topbiz.cn), but the lack
                  of open and interoperable standards means that users of one system
                  could not (reliably) communicate with users of another system.
                  Therefore, the Internet community would benefit from the development
                  of an open and interoperable IETF IMA standard.
               
               
               JET                    Expires - December 2005               [Page 2]


               Internet draft                   IMA                        June 2005
               
               
               
               3. Requirements
               
                  Any IMA solution should qualify the following requirements:
               
                  3.1 Short term (2-5 years) solution
               
                  The solution should not extend too long, so that IMA can be adopted
                  as soon as possible by interested companies. The solution also should
                  be easily deployable, so that IMA can be easily deployed by most
                  interested organizations during 2-5 years if they wish to.
               
                  3.2 Backward compatible with the existing standards
               
                  The email service is one of the most important Internet services. Any
                  updating to Internet protocols should not interfere with the
                  operation of the Internet. The IMA solution should not break the base
                  of the email service and be backward with the existing email
                  standards.
               
                  3.3 Internationalized solution (over localized solution)
               
                  The solution should be an internationalized one rather than localized
                  one.
               
               4. Architecture
               
                  Solving the problem of IMA is not easy. We should divide it into two
                  phases. In the first phase, we consider the ACE@ACE solution, which
                  is easy to implement, backward compatible, short-term and
                  internationalized solution. In the next phase, we may consider other
                  mechanisms such as UTF-8@ACE. In the ACE@ACE solution, the local part
                  of the IMA will be converted to ASCII Compatible Encoding; IDNA
                  (RFC3490) will be applied to the domain part of the IMA. In this
                  draft, we mainly focus on the ACE@ACE solution.
               
                  4.1 Encoding
               
                  A good ACE converting algorithm should be considered according to the
                  following criteria:
                       Popularity
                       Length of the encoded name
                       Implementation easiness
                       Produce valid email address
                       Case sensitivity
                       Impact on existing protocol
               
                  4.2 Normalization (IMAprep)
               
               
               
               JET                    Expires - December 2005               [Page 3]


               Internet draft                   IMA                        June 2005
               
               
                  There are profiles for Stringprep such as Nameprep[RFC3491] dealing
                  with the IDN preparation and Nodeprep[RFC3920] for internationalized
                  node identifiers. IMAprep is introduced to prepare the local part of
                  IMA. IMAprep is a profile of Stringprep [RFC3454]. IMAprep [Appendix
                  A] is used to process only the local part of IMA, not the whole email
                  address. In IMAprep, no normalization and no case folding are needed.
                  And there must be a prohibited list, but we will not discuss details
                  of IMAprep in this draft.
               
                  4.3 Mail Delivery Agent (MDA)
               
                  MDA is a part of mail servers, which are responsible for delivery of
                  mails to local mail spool or sending out to another mail server.
                  Usually, IMA is represented in the format of UTF-8 in a host while it
                  should be converted into ACE format while being transported over the
                  wire. There are various unofficial conventions for structured local
                  parts, like owner-listname, user+tag, sublocal.local, path!user, etc.
                  When internationalized local part being converted into ACE format, it
                  actually causes some problems. Therefore, MDA may need to convert
                  internationalized local part back to UTF8 (or original encoding) for
                  further mailing processing.
               
                   4.4 Prefix
               
                  Since the prefix "xn--" had been used for IDNA, it is better that
                  other prefix such as "bq--" is used for the local part of IMA to
                  avoid of potential confusion.
               
               5. Deployment
               
                  Email is an important and popular internet service. Any new
                  deployments of SMTP servers which support IMA should not disturb the
                  running of current email system. Since all the SMTP servers around
                  the world can not support IMA immediately, ACE@ACE solution would be
                  the most harmless solution to implement and deploy.
               
               6. Potential problems
               
                   6.1 Impact to IRI
                  The mailto: schema in IRI [RFC3987] may need to be modified when IMA
                  is standardlized.
               
                   6.2 POP and IMAP
               
                   While SMTP takes care of the transportation of messages and the
                  header fields correspond to the display management by the clients,
                  POP essentially handles the retrieval of mail objects from the server
                  by a client. In order to use internationalized user names based on
                  IMA for the retrieval of messages from a mail server using the POP
               
               
               JET                    Expires - December 2005               [Page 4]


               Internet draft                   IMA                        June 2005
               
               
                  protocol, a new capability should be introduced following the POP3
                  extension mechanism [RFC 2449].
                  IMAP uses the traditional user name which is based on ASCII. IMAP
                  should be updated to support the internationalized user names based
                  on IMA for the retrieval of messages from a mail server
               
               7. Security Considerations
               
                  There have been discussions on so called "IDN-spoofing". IDN
                  homograph attacks allow an attacker/phisher to spoof the domain/URLs
                  of businesses. The same kind of attack is also possible on the local
                  part of internationalized email addresses.
               
                  IMA can also introduce new email spamming. Many local parts of IMA
                  will be the names of the person or company, which could easily be
                  used by email spammer to guess the email address to produce the
                  rubbish emails.
               
                  Email spamming may combine with email spoofing and homograph attacks,
                  making it more difficult to determine who actually sent the email.
               
                  Any solution that meets the requirements in this document must not be
                  less secure than the current Email Service. Specifying requirements
                  for internationalized email addresses does not itself raise any new
                  security issues. However, any change to the email service may affect
                  the security of any protocol that uses the email address. A thorough
                  evaluation of those protocols for security concerns will be needed
                  when they are developed.
               
               8. References
               
                  [RFC1869] Klensin,J., Freed, N., Rose, M., Stefferud, E., Crocker, D.,
                  "SMTP Service Extensions", RFC 1869, November 1995.
                  [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
                  Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
                  November 1996.
                  [RFC2449] R. Gellens, C. Newman, L. Lundblade, "POP3 Extension
                  Mechanism" RFC2449 November 1998
                  [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
                  April 2001.
                  [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
                  2001.
                  [RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized
                  Strings ("stringprep")" RFC3454 December 2002
                  [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
                  "Internationalizing Domain Names in Applications (IDNA)",RFC 3490,
                  March 2003.
                  [RFC3491] P. Hoffman , M. Blanchet, "Nameprep: A Stringprep Profile
                  for Internationalized Domain Names" RFC3491 March 2003
               
               
               JET                    Expires - December 2005               [Page 5]


               Internet draft                   IMA                        June 2005
               
               
                  [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
                  for Internationalized Domain Names in Applications (IDNA)", RFC 3492,
                  March 2003.
                  [RFC3629] Yergeau, F.,"UTF-8, a transformation format of ISO 10646",
                  RFC 3629, November 2003.
                  [RFC3920] P. Saint-Andre, "Extensible Messaging and Presence Protocol
                  (XMPP): Core", RFC3920 October 2004
                  [RFC3987] M. Duerst, M. Suignard, "Internationalized Resource
                  Identifiers (IRIs)", RFC3987 January 2005
               
               
               
               9. Authors
               
                  Xiaodong LEE (lee@cnnic.cn)
                  China Internet Network Information Center (CNNIC)
               
                  Nai-Wen Hsu (snw@twnic.net.tw)
                  Taiwan Network Information Center (TWNIC)
               
                  Yoshiro YONEYA  yone@jprs.co.jp
                  Japan Registry Services, Co. Ltd
               
                  YangWoo Ko (yw@mrko.pe.kr)
                  Korea Network Information Center
               
                  James Seng (james@seng.cc)
                  Former co-chair of IETF IDN Working Group
               
                  Editors
               
                  Jiankang YAO  (yaojk@cnnic.cn)
                  China Internet Network Information Center (CNNIC)
               
                  Jeff Yeh      (jeff@twnic.net.tw)
                  Taiwan Network Information Center (TWNIC)
               
               
               10. Acknowledgments
               
                  Authors gratefully acknowledge the contributions of:
               
                  * John C Klensin for his discussion with us in 62nd IETF meeting and
                  his internet draft about IMA
                  * Paul Hoffman and Adam M. Costello for their internet draft about
                  IMA
               
               
               
               
               
               JET                    Expires - December 2005               [Page 6]


               Internet draft                   IMA                        June 2005
               
               
                  Appendix A: IMAprep
               
               
                  Conclusion: no normalization, but there still prep needed, define our
                  own prep for the email local part
               
                     our own prep:
                        no normalization
                        no case folding
                        prohibited list - .....  (discussed later after meeting )
               
                     local part ??problem:
                        No RFC standards define this part
                        The MDA must support internationalized local part, anyway
                        No use of ACE deals the mail processing, so it should be
                  converted back to UTF8, then be dealt with the mail processing
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               JET                    Expires - December 2005               [Page 7]


               Internet draft                   IMA                        June 2005
               
               
                  Intellectual Property Statement
               
                     The IETF takes no position regarding the validity or scope of any
                  Intellectual Property Rights or other rights that might be claimed to
                  pertain to the implementation or use of the technology described in
                  this document or the extent to which any license under such rights
                  might or might not be available; nor does it represent that it has
                  made any independent effort to identify any such rights.  Information
                  on the procedures with respect to rights in RFC documents can be
                  found in BCP 78 and BCP 79.
                     Copies of IPR disclosures made to the IETF Secretariat and any
                  assurances of licenses to be made available, or the result of an
                  attempt made to obtain a general license or permission for the use of
                  such proprietary rights by implementers or users of this
                  specification can be obtained from the IETF on-line IPR repository at
                  http://www.ietf.org/ipr.
                     The IETF invites any interested party to bring to its attention
                  any copyrights, patents or patent applications, or other proprietary
                  rights that may cover technology that may be required to implement
                  this standard.  Please address the information to the IETF at ietf-
                  ipr@ietf.org.
               
               
                  Disclaimer of Validity
               
                     This document and the information contained herein are provided on
                  an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
                  REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
                  INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
                  IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
                  THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
                  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
               
               
                  Copyright Statement
               
                     Copyright (C) The Internet Society (2005).  This document is
                  subject to the rights, licenses and restrictions contained in BCP 78,
                  and except as set forth therein, the authors retain all their rights.
               
               
               
               
               
               
               
               
               
               
               
               
               JET                    Expires - December 2005               [Page 8]