[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                             J. Yao
Internet-Draft                                                    X. Lee
Intended status: Informational                                     CNNIC
Expires: January 14, 2010                                  July 13, 2009


           Guidelines for Internationalized Email Deployment
                    draft-yao-eai-deployment-03.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 January 14, 2010.

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



Yao & Lee               Expires January 14, 2010                [Page 1]


Internet-Draft               EAI Deployment                    July 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

   Key RFCs for internationalized email address have been published,
   specifying the basic protocols for using it.  This document provides
   some guidelines for implementing the email systems that support Email
   Address Internationalization (EAI).  Its aim is to give some
   suggestions and help the engineers to implement these protocols.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Role of this specification . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Deployment . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  From non-EAI world to EAI world  . . . . . . . . . . . . .  4
     2.2.  SMTP client  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Relay Server . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  SMTP Server  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.5.  Email Filter . . . . . . . . . . . . . . . . . . . . . . .  5
     2.6.  Firewall . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.7.  Mail User Agent  . . . . . . . . . . . . . . . . . . . . .  6
     2.8.  Full Support of EAI Protocols  . . . . . . . . . . . . . .  6
   3.  Alternate ASCII Address  . . . . . . . . . . . . . . . . . . .  6
   4.  Internationalized Email Domains  . . . . . . . . . . . . . . .  6
   5.  Converting Local Character Codes To UTF-8 encoding . . . . . .  7
   6.  Restrictions on Characters in Local Part . . . . . . . . . . .  7
   7.  Local Part Interpretations . . . . . . . . . . . . . . . . . .  8
   8.  Lookup in DNS  . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   12. Change History . . . . . . . . . . . . . . . . . . . . . . . .  8
     12.1. draft-yao-eai-deployment: Version 01 . . . . . . . . . . .  9
     12.2. draft-yao-eai-deployment: Version 02 . . . . . . . . . . .  9
     12.3. draft-yao-eai-deployment: Version 03 . . . . . . . . . . .  9
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     13.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     13.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






Yao & Lee               Expires January 14, 2010                [Page 2]


Internet-Draft               EAI Deployment                    July 2009


1.  Introduction

   The IETF has published five RFCs [RFC4952] [RFC5335] [RFC5336]
   [RFC5337] [RFC5504] about internationalized email addresses.  The
   goal of this document is to provide guidelines for Internationalized
   Email Address (EAI) implementations.  It highlights areas which EAI
   implementors may find valuable.  This document discusses potential
   choices that can be made in an attempt to help to foster
   interoperability between components that use the EAI protocols.  EAI
   extends the current base email standards [RFC5321] [RFC5322].  It is
   important for EAI implementors to carry out a thorough analysis of
   all of the base email standards to understand the relationships
   between those standards and the current EAI protocols.  A great deal
   of the advice for making the EAI protocols more practical is
   available to those who want to deploy the EAI protocols.  More
   discussions related to deployment reports on the prototype
   implementation and the interoperability test results, as well as the
   evaluation will be disscused in other document [DeploymentTests].

1.1.  Role of this specification

   The framework document specifies the requirements for, and describes
   components of, full internationalization of email address.  The EAI
   SMTP extension document [RFC5336] specifies the SMTP extension to use
   the internationalized email address.  The EAI header document
   [RFC5335] allows the internationalized email address headers.  The
   EAI downgrade document [RFC5504] addresses how to downgrade to be
   compatible with the current non-EAI-system.  A thorough understanding
   of the information in all these documents and in the base Internet
   email specifications [RFC5321] [RFC5322] is necessary to understand
   and implement this specification.

   This document emphasizes some points in the EAI protocols and gives
   some suggestions and advice for the usage, implementation and
   deployment of internationalized email address.

1.2.  Terminology

   All the specialized terms used in this specification are defined in
   the framework document [RFC4952], the EAI SMTP extension document
   [RFC5336], the EAI header document [RFC5335] and the base Internet
   email specifications [RFC5321] [RFC5322].  In particular, the terms
   "ASCII user", and "i18mail user" are used in this document according
   to the definitions in the framework one.

   [[anchor3: NOTE TO RFC EDITOR: Please remove the following text
   before publication.]]
   Some ideas of this specification is being discussed on the EAI



Yao & Lee               Expires January 14, 2010                [Page 3]


Internet-Draft               EAI Deployment                    July 2009


   mailing list.  See https://www1.ietf.org/mailman/listinfo/ima for
   information about subscribing.  The list's archive is at
   http://www1.ietf.org/mail-archive/web/ima/index.html.


2.  Deployment

2.1.  From non-EAI world to EAI world

   An i18mail user normally uses the EAI-capability sending server which
   his internationalized email address resides in.  It is very unlikely
   that the i18mail user use the non-EAI-capability server to send its
   i18mail message.  If that situations occures, the sending server will
   reject the message or report it as an error.  EAI Protocols are used
   to exchange the message between at least 2 SMTP servers.  If only one
   SMTP server supports the EAI protocols, that is meaningless.  When
   one email service provider implements the EAI service, it can provide
   registration of EAI account.  The EAI user can exchange the email
   within the domain.  When another email service provider supports EAI
   protocols, the EAI users within these 2 domains can exchange the EAI
   message.  When the demands for internationalized email address
   increase, more and more email service providers will support EAI.
   Although it is not possible to support EAI protocol within one night,
   it is very possible that the EAI protocol will become more popular
   with the time being.  From non-EAI world to EAI world, it is
   procedure of step by step.  More issuses about this topic will be
   discussed in other document[DeploymentTests].

2.2.  SMTP client

   The SMTP client is used to send the message.  It should implement the
   specifications in the [RFC5335] and [RFC5336].  Since many SMTP
   servers are still not ready to accept EAI messages, it is very
   important to implement the mechanisms specified in the section 3.2 in
   [RFC5336].  EAI messages can only be transferred to SMTP servers that
   support EAI.  If an alt-address is provided, it is easier for the
   sender to reach the receiver as the downgrading mechanism spcified in
   the [RFC5504] can be used.  If the SMTP client has binded the EAI
   account to the ASCII one specified in the section 3 of this document,
   the SMTP client should find the ASCII address corresponding to the
   EAI one and do some downgrading when encountering some non-EAI-aware
   SMTP server.  In other situations, the message can either be rejected
   during the SMTP transaction or the SMTP server can accept the message
   and then generate a notification of non-delivery.







Yao & Lee               Expires January 14, 2010                [Page 4]


Internet-Draft               EAI Deployment                    July 2009


2.3.  Relay Server

   It is possible that the relay server does not support EAI protocols.
   If an EAI-aware SMTP client sends the message to a non-EAI-capable
   relay server, the relay server should adopt one of the 4 methods
   specified in section 3.2 in RFC 5336 [RFC5336].  If the relay server
   is under the control of one organization which is in charge of both
   the sending systems and relay servers, it is suggested that this
   organization should update all its servers to support EAI protocols.

2.4.  SMTP Server

   If the SMTP server does not support EAI protocols, it will be not
   accept the EAI message.  If the EAI-aware SMTP server receiving the
   EAI message is the the final delivery system, the message will be
   delivered to the message store.  If the EAI-capability server
   receives the EAI message, the serve will distribute the message to
   the message store.

2.5.  Email Filter

   Many email receivers have installed the email filters.  Because EAI
   messages may have some "non-ASCII" addresses, it is very strange to
   email filters.  Sometimes the internationalized domain names will be
   transformed into punycode form when they arrived at the filters.
   These forms are ugly and often get special processing from the filter
   which suspects that the domain name with this form is randomly
   created and is used for the spam mail.  If the mail filters are not
   updated to support EAI protocols, some may regard EAI messages as the
   rubbish and drop them immediately; some may need more time to process
   the message and delay it.  It is suggested that the email filter
   should be updated to accept EAI messages too when email server is
   updatd.

2.6.  Firewall

   Firewall document [RFC2979] requires to perform extensive protocol
   validity checks.  Specially, in section 3.1.2 of RFC 2979 [RFC2979]
   The firewall will scan the list of EHLO responses and only allow the
   ones the firewalls understands through.  The traditional fireall will
   not understand the keyword "UTF8SMTP", lead to unnecessary protocol
   failures, and cut off the SMTP connection.  Some firewalls will be
   acted as the SMTP relay or agent.  These firewalls should be updated
   to support EAI protocols.







Yao & Lee               Expires January 14, 2010                [Page 5]


Internet-Draft               EAI Deployment                    July 2009


2.7.  Mail User Agent

   The IETF has defined the protocols required to exchange EAI messages
   between SMTP senders and SMTP receivers.  If you want to use
   internationalized email addresses, it is very vital that other parts
   such as the Mail User Agent (MUA) supports EAI protocols.  Since most
   MUAs do not support internationalized email addresses, the MUA may
   not be able to send EAI messages on behalf of the email user and
   fetch EAI messages from the message store.  For better use of EAI,
   MUAs should be upgraded to support EAI protocols.

2.8.  Full Support of EAI Protocols

   The email system is very complex.  Many parts of the email system
   will use the email address.  It is suggested that all parts of the
   email system should be upgraded to support EAI protocols.


3.  Alternate ASCII Address

   There are millions email servers and clients.  They cannot be updated
   to support EAI protocols within a night.  EAI protocols specify a
   transitional mechanism which allows the EAI-capable SMTP clients to
   talk with the non-EAI SMTP servers.  During the deployment of EAI, it
   is impossible to upgrade all SMTP clients and SMTP servers to support
   EAI.  The SMTPext document [RFC5336] specifies an ALT-ADDRESS
   parameter for use when downgrading is required.  Only EAI users may
   require the Alternate ASCII Addresses, ASCII users has no need for
   it.  It is recommended that Alternate ASCII Addresses should not be
   used by ASCII users as a general-purpose second-chance email address.
   When the email user signs up for an internationalized email account,
   it is better that the system automatically binds it with an Alternate
   ASCII Address.  This email account's name may be selected by email
   account applicant.  The Alternate ASCII Address is used for the ALT-
   ADDRESS parameter.  It can be an alias of the EAI account.  Both the
   internationalized email address and Alternate ASCII Address refer to
   the same message store.  This method has an advantage: When the EAI
   user sends an email to other user, he or she does not need to fill in
   an ASCII email address for the ALT-ADDRESS parameter when the
   receiver does not support EAI.  The EAI-capable SMTP system
   automatically provides the Alternate ASCII Address which was prepared
   in advance when the user signed up for an internationalized email
   account.


4.  Internationalized Email Domains

   The email service provider could have both an internationalized email



Yao & Lee               Expires January 14, 2010                [Page 6]


Internet-Draft               EAI Deployment                    July 2009


   domain and an ASCII email domain.  The ASCII domain can be regarded
   as the alias of the internationalized domain.  The MX records for
   both domains point to the same target host.


5.  Converting Local Character Codes To UTF-8 encoding

   Some systems, operating in local environments, will use local
   character codes no matter what we specify.  In many countries, there
   are local national standards for character encoding.  For example, in
   China, GB2312 and GB18000 is the national standards.  Japan has also
   its own national character encoding standards.  So there are some
   reasons for permitting local-parts to be written in locally-used
   character codes other than the UTF-8 encoding of UNICODE.  On the
   other hand, having an application presented with an octet (or bit)
   string and not knowing what charset is involved would block the
   attempt to intelligently display local parts.  The EAI protocol
   allows only UTF-8 encoding in the local part in the email header and
   envelop.  The MUA may display the message information with the local
   character codes.  But when the email address information is
   transferred on the wire, it must use the UTF-8 encoding other than
   local character encodings.  Use of local coding also implies an
   encoding for the local part different from that for the domain part.
   The domain part of the internationalized email address will support
   IDNA [RFC3490] and uses the UTF-8 encodings.  If local codings can be
   avoided entirely, it will considerably reduce complexity and
   "opportunities" for systems to not interoperate.


6.  Restrictions on Characters in Local Part

   The EAI specification is extremely liberal about what can be included
   in a UTF-8 string that represents a local-part.  It prohibits the use
   of quoted strings, or quoted characters, in non-ASCII local parts.
   Quoted strings and characters in local parts have, in general, been
   nothing but trouble and there appears to be no reason to carry that
   trouble forward into an internationalized world.  It is suggested
   that applying restrictions by use of a stringprep [RFC3454] profile
   that would eliminate particularly problematic characters is
   suggested.  IDNAbis label check may be used for local parts.  Some
   languages characters has some special features.  For example, Chinese
   characters has some varants.  When registering the email account, the
   technique specified in the RFC 3743 may be used for the possible
   confusion.  ASCII local-parts are inherently case sensitive.  The
   local systems are encouraged to not take advantage of that feature.
   All internationalized email local part are suggested to be case
   insensitive.




Yao & Lee               Expires January 14, 2010                [Page 7]


Internet-Draft               EAI Deployment                    July 2009


7.  Local Part Interpretations

   In the Internet email context, the interpretation and permitted
   syntax for an email local-part is entirely the responsibility of the
   receiving system.  The general advice to system designers still
   include "treat addresses in a case-independent fashion" and "do not
   use addresses that require quoting".  Senders should continue to be
   conservative about what they send, and relays should continue to
   avoid presumptions about their understanding of the content of local-
   parts.  Receiving systems that have reason to adopt more restricted
   syntax rules, or interpretations of matching, should continue to be
   able to do so.


8.  Lookup in DNS

   The domain part of the email address is used to route the message to
   the proper destination.  The domain part must be processed into the
   punycode form specified in RFC 3490 [RFC3490] before DNS lookup.


9.  IANA Considerations

   There is no IANA consideraton.


10.  Security Considerations

   See the extended security considerations discussion in the framework
   document [RFC4952].


11.  Acknowledgements

   Many ideas are from the discussion in the list ima@ietf.org.  John C
   Klensin has done a lot of reasearch on ASCII email address and
   internationalized email address.  I got many significant words or
   ideas from him.  Many friends and experts in the EAI WG help us to
   produce the valuable ideas.  Many organizations including CNNIC,
   TWNIC, JPRS, NIDA, AND AFFLILIAS have implemented EAI systems.  These
   organizations have already done a lot of inter-operating testing.  S.
   Moonesamy gives many kind comments to draft version 01.  Thanks John
   C Klensin for his comments to Draft version 02.


12.  Change History

   [[anchor12: RFC Editor: Please remove this section.]]



Yao & Lee               Expires January 14, 2010                [Page 8]


Internet-Draft               EAI Deployment                    July 2009


12.1.  draft-yao-eai-deployment: Version 01

   o  update the section "Sending Server"
   o  add the new section "From non-EAI world to EAI world"
   o  update and refine the texts of this document

12.2.  draft-yao-eai-deployment: Version 02

   o  rename the section "Sending Server" to "SMTP client"
   o  rename the section "Recieve Server" to "SMTP server"
   o  add the new section "Internationalized email domain"
   o  move and refine the section "Firewall"
   o  update and refine the texts of this document

12.3.  draft-yao-eai-deployment: Version 03

   o  rename the draft title from "eai deployment practise" to
      "Guidelines for Internationalized Email Deployment"
   o  remove the section "Test Scenarios"
   o  remove the section "Test Results and Experiences"
   o  update and refine the texts of this document


13.  References

13.1.  Normative References

   [ASCII]    American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange", ANSI X3.4-1968, 1968.

   [RFC1652]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
              RFC 1652, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2979]  Freed, N., "Behavior of and Requirements for Internet
              Firewalls", RFC 2979, October 2000.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes",
              RFC 3463, January 2003.




Yao & Lee               Expires January 14, 2010                [Page 9]


Internet-Draft               EAI Deployment                    July 2009


   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 3629, November 2003.

   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

   [RFC4952]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 4952, July 2007.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5335]  Abel, Y., "Internationalized Email Headers", RFC 5335,
              September 2008.

   [RFC5336]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
              Email Addresses", RFC 5336, September 2008.

   [RFC5337]  Newman, C. and A. Melnikov, "Internationalized Delivery
              Status and Disposition Notifications", RFC 5337,
              September 2008.

13.2.  Informative References

   [DeploymentTests]
              YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test
              and Evaulation for EAI deployment",
              draft-yao-eai-tests-00.txt (work in progress),
              August 2009.

   [RFC5504]  YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading
              mechanism for Internationalized eMail Address", RFC 5504,
              3 2009.











Yao & Lee               Expires January 14, 2010               [Page 10]


Internet-Draft               EAI Deployment                    July 2009


Authors' Addresses

   Jiankang YAO
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing

   Phone: +86 10 58813007
   Email: yaojk@cnnic.cn


   Xiaodong LEE
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing

   Phone: +86 10 58813020
   Email: lee@cnnic.cn

































Yao & Lee               Expires January 14, 2010               [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/