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 <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
[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 <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
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]
