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 draft-ietf-eai-email-clients-00 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- 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 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 (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 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 environments. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 usability. 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 providers. 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- house. 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 Address. Original header: From: Display-Name > 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?= Downgraded-From: =?UTF-8?Q?Display-Name?= =?UTF-8?Q?> 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 [RFC5504]. 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 messages. 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 [draft-ietf-eai-downgraded-display]. 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-" headers. 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 process. 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 (DSN). 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 UTF8SMTP. 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 Addresses. 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 > 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 > 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 mailboxes. 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 FULLWIDTH COMMERCIAL AT (U+FF20) with ASCII "@", COMMERCIAL AT (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 user@host*domain where * represents IDEOGRAPHIC FULL STOP (U+3002), as used in some Asian languages, would display as user@host.domain 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 2009. [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 2001. [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 Canada Email: edainow@ca.afilias.info Kazunori Fujiwara JPRS Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: fujiwara@jprs.co.jp Dainow & Fujiwara Expires January 8, 2010 [Page 16]