Network Working Group                                         E. Dainow
Internet-Draft                                                  Afilias
Intended status: Experimental                               K. Fujiwara
Expires: January 8, 2010                                           JPRS
                                                           July 8, 2009

              Guidelines for Internationalized Email Clients

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 8, 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
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document provides some guidelines for email clients that support
   Email Address Internationalization (EAI) as outlined in RFC 4952. A
   number of interoperability cases between different versions of email
   components are reviewed. Recommendations are made to improve

Dainow & Fujiwara      Expires January 8, 2010                 [Page 1]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   interoperability and usability and to minimize discrepancies between
   the display of composed and received email in different language

Table of Contents

   1. Conventions used in this document..............................3
   2. Introduction...................................................3
      2.1. Terminology...............................................3
   3. Version Interoperability.......................................4
      3.1. Sending...................................................6
         3.1.1. Downgrade............................................7
      3.2. Receiving.................................................8
         3.2.1. Display of Downgraded Messages As Received...........9
         3.2.2. Downgraded Display...................................9
   4. Alternate Addresses...........................................10
      4.1. Sender...................................................10
      4.2. Recipients...............................................11
      4.3. Entry and Display of Alternate Addresses.................11
      4.4. Mailbox Integration......................................12
   5. Character Encoding............................................13
   6. Normalization.................................................13
   7. Security Considerations.......................................14
   8. IANA Considerations...........................................14
   9. Acknowledgments...............................................14
   10. References...................................................14
      10.1. Normative References....................................14
      10.2. Informative References..................................16
   Author's Addresses...............................................16

Dainow & Fujiwara      Expires January 8, 2010                 [Page 2]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2. Introduction

   [RFC 4952] Overview and Framework for Internationalized Email
   describes changes to electronic mail (email) to fully support
   internationalized characters. The fundamental change is to remove the
   ASCII only restriction on email addresses and allow them to contain
   UTF-8 characters. Additional documents provide detailed
   specifications for the extensions required to email headers [RFC5335]
   and to the protocols SMTP [RFC5336], POP [draft-ietf-eai-pop] and
   IMAP [draft-ietf-eai-imap-utf8].

   This document provides guidelines for email clients that support
   these specifications for Email Address Internationalization (EAI). It
   does not introduce any protocol extensions that are not defined in
   the above documents. It highlights the extensions that are important
   to the design and implementation of email clients and makes a number
   of recommendations intended to improve interoperability and

2.1. Terminology

   A number of different acronyms are typically used to describe the
   major functional components of email.

      Mail User Agent (MUA)
      Message Submission Agent (MSA)
      Message Transfer Agent (MTA)
      Message Delivery Agent (MDA)
      Message Store (MS)

   The architecture of modern email systems can range from simple, with
   all components running on one server, to very complex, with
   components being distributed across multiple, geographically
   dispersed machines. Nevertheless, the above terminology is generally
   sufficient to represent different architectures from a functional
   point of view. For a comprehensive description of email architecture
   see [draft-crocker-email-arch].

Dainow & Fujiwara      Expires January 8, 2010                 [Page 3]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   sender -> MUA -> MSA -> MTA
                           MTA -> MDA -> MS -> PIF -> MUA -> recipient

   (where ... represents possible additional MTA relays)

   In this context, an "Email Client" is an MUA that has an interface to
   an MSA to send email and an interface to the MS to retrieve email.
   The interface to retrieve mail (PIF) is a POP or IMAP server or
   direct access to the File system. The MUA also provides a User
   Interface (UI) that allows an end user to read (display) and write
   (compose) their email.

   A common email architecture includes the MSA function within the MTA.
   An improved architecture that better addresses security concerns is a
   separate MSA component as shown here [RFC4409], [RFC5068].

   "UTF8SMTP" is used to indicate email address internationalization as
   specified by [RFC4952] and related documents.

   "ASCII" refers to the strict 7-bit ASCII character set [ASCII].

   "UTF-8", Unicode Transformation Format/8-bit is a character encoding
   scheme that can represent any character in the Unicode standard
   [RFC3629]. It contains ASCII as a subset.

   "message/global" is an email message that contains UTF-8 characters
   beyond 7-bit ASCII in message headers and/or body parts [RFC5335].

   "message/rfc822" is an email message that contains only 7 bit ASCII
   and does not use any UTF8SMTP extensions. Note that the original
   message (as composed by the user) may contain non-ASCII characters
   that have been encoded into ASCII using IDNA [RFC3490], MIME body
   encoding [RFC2045] or MIME header encoding [RFC2047].

3. Version Interoperability

   Not all the components in Internet email systems will get upgraded to
   UTF8SMTP at the same time. There will be a transition period where
   upgraded components should be backwards compatible with traditional
   email components.

   The following table characterizes the most typical (but not all the
   possible) email paths between users in different organizations or
   enterprises (E1, E2, etc.) and highlights the boundaries where
   incompatibilities will occur most frequently.

   Cases where email does not cross a jurisdictional boundary between
   sender and receiver are not shown. This includes email between users

Dainow & Fujiwara      Expires January 8, 2010                 [Page 4]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   within the same organization and email between users in different
   organizations who use the same third party mail service.

             | Sending             |Receiving
         Case| MUA |MSA |MTA...MTA |MTA...MTA |MDA |MUA |
          1  | E1------------------|E2-------------->   |
          2  | E1--|E2-------------|E3-------------|E4  |
          3a | E1--|E2-------------|E3-------------->   |
          3b | E1------------------|E2-------------|E3  |

   It is assumed in all cases that SMTP mail between MTAs uses DNS.
   Lookup of the MX record for the destination domain means that there
   is only one boundary of incompatibility between MTAs.

   Case 1 represents the larger organizations and expert users who
   manage their own email infrastructure. In these environments there
   will likely be a coordinated effort to upgrade all components of the
   email system together. Each organization typically has several MTAs
   that act as virus scanners, spam filters, mail relays and gateways to
   manage mail across different divisions and locations of the
   organization. The boundary of incompatibility is the MTA between the
   organizations. If both enterprises support UTF8SMTP, they will be
   able to send Internationalized email without the risk of
   incompatibility or Downgrade.

   For large organizations that allow end users to select and install
   their own email client software, the MUA boundaries are also possible
   incompatibilities. Users in this category would actually be
   represented by cases 2 and 3.

   Case 2 represents the home user and small to medium sized businesses
   who use the email infrastructure of a third party, such as an ISP
   (Internet Service Provider) or an outsourced provider. The mail
   provider has an infrastructure similar to Case 1. The boundaries of
   incompatibility are at the MUA and between the MTAs of the email

   Case 3 covers mixed cases where a user with an outsourced email
   service sends to or receives from a user in an organization that
   manages its own email infrastructure. The boundaries of
   incompatibility correspond to Cases 1 and 2. These cases may also
   apply to some applications within larger organizations. For example,
   cell phone email may utilize a mail gateway from a third party
   provider even though the rest of the email infrastructure is in-

   For an MUA, the boundaries where version compatibility is most likely
   to occur is between home/small office users and their email

Dainow & Fujiwara      Expires January 8, 2010                 [Page 5]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   providers. The worst case scenario is Case 2, where three boundaries
   of incompatibility are possible between sender and recipient.

3.1. Sending

   For an MUA that supports UTF8SMTP, there is a matrix of possibilities
   based on whether the email envelope and the message contain non-ASCII
   characters and whether the MSA supports the UTF8SMTP extensions or
   not. The following table shows all the possible combinations.

      Case|Envelope  |Message  |MSA is  |MUA sends
          |          |         |UTF8SMTP|
       1  |UTF8SMTP  |global   |Yes     |UTF8SMTP
       2  |UTF8SMTP  |rfc822   |Yes     |UTF8SMTP
       3  |ASCII     |global   |Yes     |UTF8SMTP
       4  |ASCII     |rfc822   |Yes     |Traditional email
       5  |UTF8SMTP  |global   |No      |Reject/Downgrade
       6  |UTF8SMTP  |rfc822   |No      |Reject/Downgrade
       7  |ASCII     |global   |No      |Reject/Downgrade
       8  |ASCII     |rfc822   |No      |Traditional email

   The Envelope and the Message type are considered separately because
   the Envelope may contain, for example, email addresses that are all
   ASCII but the Subject or other header fields in the Message may
   contain non-ASCII (Cases 3, 7).

   Cases 2 and 6 are unusual since a UTF8SMTP address in the envelope is
   usually also in the message header. An example of when this can occur
   is when an rfc822 message is forwarded with server-based forwarding
   (as with a .forward file) to a UTF8SMTP address.

   Cases 1-3

   Messages containing non-ASCII characters SHOULD be sent using the
   UTF8SMTP extensions in preference to older encoding methods, such as
   IDNA [RFC3490] and MIME header encoding [RFC2047]. If the message
   body contains non-ASCII characters, it SHOULD be sent using 8BITMIME
   [RFC1652] instead of MIME body encoding such as quoted-printable or
   base64 [RFC2045].

   Cases 5-7

   This could be considered a configuration error. If the MSA does not
   support UTF8SMTP, the user should upgrade the MSA, or switch to an
   email provider that supports UTF8SMTP.

Dainow & Fujiwara      Expires January 8, 2010                 [Page 6]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   Upgrading the MSA is a reasonable approach in the case of larger
   organizations, where an IT group would be expected to synchronize MUA
   and MSA versions. However, home/small office users may end up in this
   situation when they have a computer that came with UTF8SMTP email
   client software and their Internet Service Provider (ISP) does not
   support UTF8SMTP.

   In these cases, the MUA MUST NOT submit a message with UTF8SMTP
   headers if the MSA does not support the UTF8SMTP extensions
   [RFC5336]-Section 3.2.

   If the message is not submitted, some guidance should be provided to
   the user about how to correct the problem. It may also be desirable
   to save this status and highlight it for the user before they compose
   a message. This would provide advance warning that internationalized
   email cannot be sent.

3.1.1. Downgrade

   The MUA MAY support the "downgrade" option, which is specified as an
   option for all email components MUA, MSA, MTA and MDA. Downgrade
   builds a message with all ASCII headers so that it is compatible with
   email components that don't support the UTF8SMTP extensions.
   Downgrade basically redirects mail from a UTF8SMTP address to an
   Alternate ASCII Address [RFC5504].

   It is not recommended that the MUA support Downgrade for cases 5-7.
   The user should be encouraged to correct the configuration and
   upgrade the MSA or switch email providers in order to get support for
   internationalized email.

   The following shows an example of downgrading a "From" header with a
   non-ASCII "Display-Name", non-ASCII email address and ASCII Alternate

   Original header:

       From: Display-Name <eai-addr <alt-ascii-addr>>

   Downgrade would change the From address to the Alternate Address and
   preserve the EAI address in a new "Downgraded-From" header.

       From: =?UTF-8?Q?Display-Name?= <alt-ascii-addr>
       Downgraded-From: =?UTF-8?Q?Display-Name?=
        =?UTF-8?Q?<eai-addr?= <alt-ascii-addr>>

   Note that the Display-Name in the From header is encoded using
   traditional MIME email standards [RFC2047] with charset UTF-8. The

Dainow & Fujiwara      Expires January 8, 2010                 [Page 7]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   MUA at the recipient end does not need to support the UTF8SMTP
   extensions to decode and display the original name.

   Complete examples of Downgrade are shown in the Appendix of

3.2. Receiving

   The matrix of possibilities is based on the email message type and
   whether IMAP/POP and the MUA support the UTF8SMTP extensions or
   not(Y/N) [draft-ietf-eai-imap-utf8], [draft-ietf-eai-pop].

      Case|Original|Spooled   |IMAP|Transfered|MUA|Displayed
          |Message |Message   |/POP|Message   |   |Message
       1  |global  |global    | Y  |global    | Y |global
       2  |global  |global    | Y  |downgraded| N |downgraded
       3  |global  |global    | N  | -        |Y/N| -
       4a |global  |downgraded|Y/N |downgraded| Y |downgraded
       4b |global  |downgraded|Y/N |downgraded| Y |global
       5  |global  |downgraded|Y/N |downgraded| N |downgraded
       6  |rfc822  |rfc822    |Y/N |rfc822    |Y/N|rfc822

   Note that the cases in which the recipient receives the message as
   sent are 1 (all UTF8SMTP), 6 (traditional email) and 4b (downgraded
   conversion display).

   In cases 2, 4a and 5 the recipient receives a downgraded message.

   Case 2

   IMAP or POP must support Downgrade for this configuration. Direct
   maildrop access for message/global is prohibited if the MUA does not
   support UTF8SMTP.

   Case 3

   This is a configuration error. If IMAP or POP does not support
   UTF8SMTP, then it is not possible for the MUA to receive global

   Cases 4-6

   An ASCII message may be received from either a UTF8SMTP or a non-
   UTF8SMTP interface.

   It is possible that the original message was a UTF8SMTP message that
   got downgraded to ASCII in transit. A message can be identified as

Dainow & Fujiwara      Expires January 8, 2010                 [Page 8]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   downgraded because it will have one or more headers that are prefixed
   with "Downgraded-".

   (Case 4a) A UTF8SMTP compliant MUA MAY display a downgraded message
   as received, or (Case 4b) it MAY apply a conversion to restore the
   information contained in the "Downgraded-" headers as specified in

3.2.1. Display of Downgraded Messages As Received

   Cases 2, 4a, 5

   When displaying a downgraded message as received, UTF8SMTP addresses
   that had Alternate Addresses in the original email will not be shown
   in the headers when reading, replying or forwarding email. Only the
   Alternate Addresses will be shown.

   If a UTF8SMTP address in the original email did not have an Alternate
   Address, then the UTF8SMTP address will be displayed in an empty
   group (using ":;") to note that a UTF8SMTP address has been removed
   [RFC5504]-Section 5.1.7. This may appear in any header such as To: or
   Cc: as

      Display-Name Internationalized Address eai-addr Removed:;

   If a user replies to an email with such a group, many MUAs do not
   handle this correctly. Observed behavior has ranged from refusing to
   send the message due to an "invalid address", or attempting to send
   to the group and reporting a DSN failure, or deleting the group
   altogether. The user may resort to removing the group in order to get
   around these problems. Recipients of such email will not have an
   accurate record of who the original recipients were. MUAs should be
   upgraded to support groups, as defined in [RFC2822]-Section 3.4.

   Note that even if an MUA does not support UTF8SMTP (Cases 2, 5), it
   is able to decode and display "Downgraded-" header fields because
   Downgrade uses MIME encoding [RFC 2047][RFC 2231].

3.2.2. Downgraded Display

   Case 4b

   Support for conversion of "Downgraded-" headers is separate from
   support for Downgrade. An MUA MAY support none or one or both of
   these options.

   Conversion replaces the Alternate Addresses in email headers with the
   original UTF8SMTP addresses that were recorded in the "Downgraded-"

Dainow & Fujiwara      Expires January 8, 2010                 [Page 9]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   If the MUA supports conversion of "Downgraded-" headers, the
   following considerations should be taken into account:

  1. If the MUA receives mail from an IMAP/POP server, the conversion
     may have already been done but the message will still contain
     "Downgraded-Mail-From" and "Downgraded-Rcpt-To" headers.

  2. Conversion of Downgraded headers is not a reliable, reversible

  3. There is no authenticated binding between the original UTF8SMTP and
     the downgraded Alternate Address. This introduces various security
     concerns [draft-ietf-eai-downgraded-display]-Section 5.

4. Alternate Addresses

   Alternate Addresses MAY be required for Downgrade, which may occur
   anywhere on the path that a non-UTF8SMTP email component is
   encountered [RFC5336]-Section 3.2. If Downgrade cannot be done in
   these cases, the email may be returned ("bounced").

   Downgrade is expected to be important initially during a transition
   period but less important over time as more email systems upgrade to
   the UTF8SMTP extensions. To the extent that Downgrade is deemed
   important at the time an implementation is undertaken, Alternate
   Addresses [RFC5336] SHOULD be supported.

4.1. Sender

   An Alternate Address for the sender MAY be provided, so that after
   Downgrade there is a return path for delivery status notifications

   Email addresses are generally created and set up on the server side,
   not by the MUA. An email provider may wish to set up an Alternate
   Address automatically for each UTF8SMTP account that is created.
   While in some environments it may be difficult or unfamiliar for a
   user to enter ASCII characters, selecting an Alternate Address for
   the user's UTF8SMTP address SHOULD NOT be done automatically.
   Automatic generation often results in usability problems when names
   that are difficult to read or pronounce are produced. Any generation
   of an Alternate Address should be presented to the user as a
   suggestion that can be changed.

   A UTF8SMTP implementation of an MSA/MTA may provide the ability to
   bind an Alternate Address to a UTF8SMTP address. In this case, the
   MUA may not need to provide Alternate Addresses for the sender.

Dainow & Fujiwara      Expires January 8, 2010                [Page 10]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   However, users may wish to use different Alternate Addresses than
   those created for their UTF8SMTP email account, such as when they
   already have an ASCII address on another email system.

   In general, the MUA SHOULD allow users to save an Alternate Address
   for the sender's UTF8SMTP address, typically under "Account"
   settings. The configured value of this field is used as an ALT-
   ADDRESS parameter on the SMTP command "MAIL FROM:" and in From:
   message headers.

4.2. Recipients

   There are two cases where Downgrade can occur:

  1. Mail sent from a UTF8SMTP user to a non-UTF8SMTP user.

  2. Mail sent from a UTF8SMTP user to a UTF8SMTP user where a non-
     UTF8SMTP component is on the path.

   Downgrade in Case 1 provides backwards compatibility with recipients
   who are not UTF8SMTP. In this case, the recipient has an ASCII
   address and an Alternate Address is not required.

   In Case 2, Downgrade REQUIRES an Alternate Address for the recipient.
   However, this case could be considered a configuration error. As
   reviewed in section 3, when DNS is used to determine the transport
   path from sender to receiver, mail does not get routed through an
   email relay of a third party. If the sender and recipient both have
   UTF8SMTP addresses, then one of their MTA mail relays was not
   upgraded to UTF8SMTP. Users should only be set up with UTF8SMTP
   addresses if all the mail relays within the organization support

   If it is decided that it is important to support Downgrade for Case
   2, then the MUA SHOULD allow the user to enter and edit an optional
   Alternate Address wherever a UTF8SMTP recipient address can be
   entered and edited. This would typically be message headers when
   composing email and entries stored in an "Address Book".

   The recipient Alternate Address, if provided in an email composition,
   is used as an ALT-ADDRESS parameter on the SMTP command "RCPT TO:"
   and in message headers where the recipient address is used.

4.3. Entry and Display of Alternate Addresses

   The following applies to both sender and recipient Alternate

   Alternate Address fields MUST NOT contain non-ASCII addresses.

Dainow & Fujiwara      Expires January 8, 2010                [Page 11]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   If the main email address is not UTF8SMTP, then entering an address
   in the Alternate Address field SHOULD NOT be allowed [RFC5336]-
   Section 3.4.

   The following is one example of how to display Alternate Addresses,
   by using the UTF8SMTP "double angle bracket" format defined in
   [RFC5335]-Section 4.4:

      Display-Name <eai-addr <alt-ascii-addr>>

   It would be helpful to display an indicator on UTF8SMTP email
   addresses that do not have an Alternate Address. This would alert the
   user to the possibility that the message may bounce. In the example
   above, an empty double bracket could be displayed in a highlighted
   color, reminding the user to provide the missing alternate address,
   as in

      Display-Name <eai-addr < >>

   When sending the message, the MUA would have to remove empty double
   angle brackets.

   Since Downgrade and Alternate Addresses may not be widely used after
   a transition period, such an indicator should be configurable so that
   a user is able to turn it off.

4.4. Mailbox Integration

   If Alternate Addresses are supported, it may be desirable to combine
   mail for the UTF8SMTP address and the Alternate Address into one
   mailbox so that all related mail can be managed in one place.

   For example, if a message is sent from a UTF8SMTP address to a list
   of recipients, some of the messages may be downgraded. Replies to
   downgraded messages will be delivered to the Alternate Address, so
   all the replies to a message may be split across two different

   Mailbox integration is not generally handled by an MUA. Many existing
   MTAs/MDAs can do this with a mail "alias" or "forward". One address
   is selected as the primary mailbox and the other address is
   configured as an alias.

   Forwarding allows an email address on one email provider to be
   integrated into the mailbox on another email provider. Mailbox
   integration can make it easier for users to migrate from an old email
   system that does not support UTF8SMTP to a newer one that does. All
   they need to do is forward their old email address to an Alternate
   Address that was created on their new mail service.

Dainow & Fujiwara      Expires January 8, 2010                [Page 12]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

5. Character Encoding

   Email message bodies may be composed and displayed using many
   different character encoding schemes. Numerous character encodings
   have been developed over time in order to best represent different
   language scripts. In recent years there has been a trend to prefer
   Unicode as a "universal" character set and UTF-8 as the preferred
   encoding method.

   A good general principle to follow is to minimize character
   conversions. This will reduce the chance that the received message is
   displayed differently from how it was composed. Displaying received
   mail SHOULD use the character encoding of the received mail.

   Since older MUAs may not be able to parse UTF-8, the MUA SHOULD try
   to reply to mail using the character encoding of the received mail.
   This may not be possible if the sender adds new characters that
   cannot be encoded in the original encoding. For example, if the
   received message is encoded in ISO-2022-JP and characters in ISO-
   8859-1 are added to the message, the text cannot be carried in ISO-
   2022-JP and conversion to UTF-8 may be the best solution.

   For new mail, A UTF8SMTP compliant MUA SHOULD use UTF-8 as the
   default encoding if the message type is global or if the envelope
   contains non-ASCII addresses. If email clients utilize this default,
   character conversions will be minimized and there will be less chance
   that someone will receive mail in an unrecognized encoding.

   If the message type is rfc822, other considerations may apply, such
   as using the system locale/language.

   Notwithstanding the above, there may be cases where the default does
   not work well. There SHOULD be options for the user to reset the
   default character encoding. There SHOULD also be options to change
   the encoding when reading or writing individual email messages.

6. Normalization

   Different sequences of UTF-8 characters may represent the same thing.
   Normalization is a process that converts all canonically equivalent
   sequences to a single unique form.

   For example, in the Japanese environment, special consideration is
   needed for the "@" symbol used to separate the local name from the
   domain name in email addresses. Normalization is necessary to replace
   (U+0040) for proper parsing of email addresses.

Dainow & Fujiwara      Expires January 8, 2010                [Page 13]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   Normalization of email headers is specified in [RFC 5335]-Section
   4.1. The MUA SHOULD normalize all email addresses in the envelope and
   message headers.

   If the MUA saves email addresses (such as in an address book), they
   SHOULD be stored in normalized form. For example, an email address
   entered as


   where * represents IDEOGRAPHIC FULL STOP (U+3002), as used in some
   Asian languages, would display as


   For message bodies that contain UTF-8 characters (message/global),
   the "Net-Unicode" standardized text transmission format specified in
   [RFC5198] SHOULD be followed. It covers both normalization and
   control characters that may affect display of text.

7. Security Considerations

   This document does not introduce any security considerations beyond
   those already covered by the normative references for Email Address
   Internationalization (EAI).

8. IANA Considerations

   IANA changes are covered by the normative references for Email
   Address Internationalization (EAI).

9. Acknowledgments

10. References

10.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.

           ANSI X3.4-1968 has been replaced by newer versions with
             slight modifications, but the 1968 version remains
             definitive for the Internet.

Dainow & Fujiwara      Expires January 8, 2010                [Page 14]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   [draft-ietf-eai-downgraded-display] Fujiwara, K., "Displaying
             Downgraded Messages for Email Address
             Internationalization", draft-ietf-eai-downgraded-display-01
             (work in progress), March 2009.

   [draft-ietf-eai-imap-utf8] Resnick, P. and Newman, C., "IMAP Support
             for UTF-8", draft-ietf-eai-imap-utf8-04 (work in progress),
             June 2009.

   [draft-ietf-eai-pop] Newman, C. and Gellens, R., "POP3 Support for
             UTF-8", draft-ietf-eai-pop-06 (work in progress), June

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

   [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
             Extensions (MIME) Part One: Format of Internet Message
             Bodies", RFC 2045, November 1996.

   [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
             Part Three: Message Header Extensions for Non-ASCII Text",
             RFC 2047, November 1996.

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

   [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
             Part Three: Message Header Extensions for Non-ASCII Text",
             RFC 2047, November 1996.

   [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April

   [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",
             STD 63, RFC 3629, November 2003.

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

   [RFC5198] Klensin, J. and Padlipsky, M., "Unicode Format for Network
             Interchange", RFC 5198, March 2008.

Dainow & Fujiwara      Expires January 8, 2010                [Page 15]

Internet-Draft     Guidelines for EAI Email Clients           July 2009

   [RFC5335] Yeh, J., "Internationalized Email Headers", RFC 5335,
             November 2008.

   [RFC5336] Yao, J. and W. Mao, "SMTP extension for internationalized
             email address", RFC 5336, September 2008.

   [RFC5504] Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for
             Email Address Internationalization", RFC 5504, March 2009.

10.2. Informative References

   [draft-crocker-email-arch] D. Crocker, "Internet Mail Architecture",
             draft-crocker-email-arch-14 (work in progress), June 2009.

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

   [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E. and
             Finch, T., "Email Submission Operations: Access and
             Accountability Requirements", RFC 5068, November 2007.

Authors' Addresses

   Ernie Dainow
   Afilias Canada
   4141 Yonge Street
   Toronto, Ontario M2P 2A8


   Kazunori Fujiwara
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065


Dainow & Fujiwara      Expires January 8, 2010                [Page 16]