draft-ietf-idn-mua-00.txt

bind-3.2.

For example, for input of Chinese characters, some users use IMEs
which support the "Pinyin" input method. When a user types "zhongguo" 
(in ASCII characters) on the keyboard and selects the characters which
represent "China" (in Chinese) from a list, the IME sends the 
international characters to the application in a user-determined 
charset (e.g. GB2312).

2.1.2 Interface between Input Method Editor and MUA Composition 
      Interface

The MUA mail composition interface (i.e. the "Compose Message"
function of the MUA) SHOULD be able to accept IDNs using 8-bit character 
encoding schemes, including those represented in any localized (e.g. 
GB2312) or internationalized (e.g. UTF-8) charsets.

This input typically takes place where e-mail addresses are entered
such as the "From", "To", "Cc", "Bcc" fields, amongst others, as IDNs 
may be used at the right-hand-side of the "@" sign in an e-mail address
(domain-parts).

The mail composition interface MAY allow ACE input for the same
reasons as specified in [IDNA], but is not recommended as ACE is opaque 
and ugly.

2.1.3 Interface between MUA Composition Interface and SMTP Client

The MUA composition interface communicates with the SMTP client in the
MUA typically through internal function calls within the software itself
or through an API. It is at this level where ACE conversion of any IDN
encountered by the MUA composition interface takes place.

Before converting the name parts of the IDN into ACE, the MUA MUST
prepare each name part as specified in [NAMEPREP]. Thereafter, the MUA 
MUST convert the name parts into ACE before passing any data to the SMTP
client.

The SMTP client then prepares the e-mail for transmission using the
SMTP protocol [RFC821], and thereafter establishes an SMTP connection 
with the user-specified SMTP server to transmit the e-mail.

It is important to note that an IDN specified in the parameters of any
SMTP command MUST be represented in nameprepped ACE at this point in 
time. This includes SMTP commands which require domain parameters (such 
as the HELO and EHLO commands) and commands where e-mail addresses are 
specified (such as the MAIL FROM, RCPT TO, DATA, VRFY, EXPN, SEND, SOML 
and SAML commands).

As for data passed by the DATA command, ACE conversion MUST be
performed when the "domain" portion of an "addr-spec" or when a "domain" 
itself, within the context of [RFC822], is encountered. This is 
necessary as an updated MUA may originate a message which is read by a 
non-updated MUA. If this happens, the non-updated MUA may face 
operational problems dealing with IDNs that appear in the "addr-spec" 
which are not in ACE.

Any transfer encoding syntax to be applied to the mail headers as
specified in [RFC2047] SHOULD be performed before nameprepped ACE 
conversion. This is to reduce confusion between IDNs within "addr-spec" 
and "domain" portions, in the context of [RFC822], and IDNs which appear 
as arbitrary data in mail headers and bodies.

2.1.4. Interface between POP3/IMAP4 client (or local mail store) and 
       Mail Reading Interface

The MUA mail reading interface (i.e. "Read mail" function of an MUA)
typically displays e-mail data retrieved from either a POP3/IMAP4
client or from a local mail store through internal function calls within 
the MUA software or through an API.

When e-mail containing an ACE-represented IDN is to be displayed, the
MUA SHOULD convert the ACE-represented IDN contained within the
"addr-spec" or "domain" portion specified in [RFC822] back into any 
localized or internationalized charset of the user's choice, whenever 
possible. In the event that it is impossible to achieve conversion back 
into the selected localized charset (for example, conversion of RACE-
represented Hangeul characters into ISO-8859-1 is impossible), the MUA 
should prompt the user with an error message.

It may be possible to save and retrieve information about the original
charset of the ACE-converted IDN through the use of additional
[RFC822] mail headers, but that is not (yet) addressed by this memo.

Although it is possible to render ACE into properly decoded glyphs and
display the actual abstract characters without any conversion to other
charsets, the MUA SHOULD NOT do this as it is not the primary function
of an MUA to render characters. This should be left to a rendering 
engine which is separate from the MUA and typically embedded into the 
OS. It is sufficient for the MUA to pass the appropriate charset to the
rendering engine for proper display.

3. ACE Length Considerations

As [RFC821] in Section 4.5.3 restricts the maximum total length of a
domain name to 64 characters, representation of IDNs using ACE may
pose a potential problem. Most ACEs typically require 3-4 ASCII 
characters to represent one international character (especially in the 
case of CJK characters, where compression is less effective).

That would leave only about 16-24 characters for the whole IDN,
including all name parts and dots. This is highly undesirable as some 
languages such as Arabic are unable to be abbreviated and the domain 
names may require a larger length than that which is allowed by 
[RFC821].

To further complicate matters, several mailing list software such as
ezmlm embed domain names into the local-parts portion of an e-mail 
address during management of subscriptions, together with randomly-
generated subscription information. This would leave an even smaller 
maximum ACE length, if interoperability with these mailing list software 
were to be maintained, given that there is also a 64 character 
restriction on local parts.

4. Security Considerations

As this memo is based on [IDNA], security considerations are similar
to that faced by [IDNA]. This includes security considerations from
[NAMEPREP] as well.

5. Other Considerations

Although this document addresses end-user MUAs (e.g. elm, mutt, pine,
Eudora, Outlook Express, etc) to a large extent, the definition of an
MUA could be extended to include web-based e-mail server software and
automated programs such as mailing list management software.

End-user MUAs may also include additional functionality where IDNs may
be encountered, such as calendaring/scheduling, directory services and
digital certificate storage. This is not (yet) addressed in this memo.

6. Future Extensions

It is possible to achieve internationalization of the entire e-mail
address by representation of international characters in the local-parts 
of an "addr-spec" using nameprepped ACE conversion in a similar fashion 
as described in this memo.

However, this is a different problem altogether and is currently beyond
the scope of this memo.

7. References

[IDNA] Paul Hoffman & Patrik Faltstrom, "Internationalizing Host Names
in Applications (IDNA)", draft-ietf-idn-idna.

[UTR17] K. Whistler & M. Davis, Unicode Consortium, "Character Encoding
Model", Unicode Technical Report #17, 
http://www.unicode.org/unicode/reports/tr17/

[US-ASCII] United States of America Standards Institute, "USA Code for 
Information Interchange", X3.4, 1968.

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

[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare.

[RFC821] Jonathan B. Postel, "Simple Mail Transfer Protocol", August 
1982, RFC 821.

[RFC822] David H. Crocker, "Standard for the Format of ARPA Internet 
Text Messages", August 1982, RFC 822.

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

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

[RFC1652] J. Klensin et al., "SMTP Service Extension for 8bit-
MIMEtransport", July 1994, RFC 1652.


[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.

A. Author's Address

Maynard Kang
i-EMAIL.net Pte Ltd
1 Kim Seng Promenade #12-07
Great World City West Tower
Singapore 237994
E-mail: [e-mail]