Internet Draft                                             Maynard Kangdraft-ietf-idn-mua-00.txt                                   i-EMAIL.netFebruary 5, 2001                                Expires on August 5, 2001                                         Internationalizing Domain Names in Mail User Agents Status of this MemoThis document is an Internet-Draft and is in full conformance with allprovisions of Section 10 of RFC2026.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and its working groups. Note that othergroups may also distribute working documents as Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference materialor 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.AbstractThis document describes a way where domain names used in Internet e-mail can be internationalized by making changes only to end-user Mail User Agents and, by doing so, avoid damaging other applications which handleInternet e-mail, such as Message Transfer Agents and Delivery Agents.1. IntroductionOne of the proposed solutions for internationalized domain names (IDN)involves only updating the user applications with no changes requiredto the DNS protocol, servers and resolvers [IDNA] compared to othersolutions which require changes to be made to protocol, servers,resolvers and applications.The underlying principle of [IDNA] may be similarly applied to theInternet e-mail system today - by effecting changes to only the MailUser Agent (MUA) component of the e-mail system. Thus, existingMessage Transfer Agents, Delivery Agents and other applications which handle e-mail do not have to be changed at all.1.1 Definitions and ConventionsUsage of terms related to the character encoding model are inreference to Unicode Technical Report 17 [UTR17].The terms "international character", "non-ASCII character" and "multilingual character", which are used interchangeably, are taken to mean any abstract character which is not included in the range specified by [US-ASCII].1.2 TerminologyThe key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119].1.3. Design PhilosophyAs the Internet e-mail system is a diverse, distributed and heterogeneous system with many vendors deploying a vast number of applications, it is of utmost importance that interoperability amongst these various components is maintained. Thus, the ideal solution would be one which does not compromise or damage the operation of any of these existing components once internationalized domain names are encountered.Also, solutions which call for changes to be made to many or even allcomponents of the Internet e-mail system would require far too muchtime and effort to deploy, given that Internet e-mail has such a hugeinstalled base.This solution adheres to both of the above principles, in thatinteroperability is preserved and that the cost and speed of implementation is low. All that the user has to do to use IDNs in e-mail is update his or her MUA.1.4. IDN SummaryThis solution specifies an IDN architecture of arch-3 (just send ACE)and a transition strategy of trans-1 (always do current plus newarchitecture) as described in [IDNCOMP]. The choice of ACE format is not defined in this document, but MUST be the same as that specified in [IDNA] in order to maintain uniqueness and consistency.1.5. E-mail Internationalization SummaryAs many Internet e-mail standards such as the SMTP protocol [RFC821]and the e-mail message format [RFC822] only specify usage of the 7-bitASCII character set [US-ASCII], international characters which use octet-based character encoding schemes (CES) cannot be used in e-mail transmission, headers and bodies.Although this issue has been addressed in [RFC2045] for message bodiesand [RFC2047] for message headers through the use of a Transfer EncodingSyntax (TES) such as Quoted-Printable or Base64, there is no similar solution which extends the functionality of [RFC821] to include usage ofinternational characters, except for [RFC1652] which allows transmission of 8-bit data passed by the DATA command in an SMTP session.[RFC1652] however, does not fully address the problem of using IDNs inan SMTP session - the IDN may be used in areas within the SMTP session other than the DATA command, such as the MAIL FROM and RCPT TO commands, where an IDN may be part of the e-mail address(es) specified there.Hence, this would be a major stumbling block to deploying "just-send-8bit" IDNs for use in Internet e-mail, as these IDNs would not be ableto be used in SMTP e-mail transmissions due to [RFC821] restrictions.2. Architectural OverviewThe end-user MUA may encounter IDNs in the scenarios below:(i)   When specifying the transmission server (i.e. SMTP server)(ii)  When specifying the retrieval server (i.e. POP3/IMAP4/any other      retrieval mechanism)(iii) When specifying e-mail addresses during composition of a message(iv)  When reading messages with e-mail addresses in itAs with [IDNA], the MUA is updated in a similar fashion to process IDNs which are input by users and process IDNs which are displayed to users, in all of the scenarios above.For (i) and (ii), the IDN MUST be handled in the same manner as specified in [IDNA]. The method of handling an IDN For (iii) and (iv) isdescribed below in 2.1.2.1 Interfaces between E-mail components when composing/reading a mailThe interfaces between e-mail components can be pictorially represented as shown below.The example assumes the setup of a POP3/IMAP4 retrieval client and server, but the exact nature of end-to-end e-mail transmission may varyaccordingly (e.g. elm or pine would read directly from the mail store). However, these variations do not impact an accurate description of this solution to a large extent as no changes are required at these levels.        +------+                                       +------+        | User |                                       | User |        +------+                                       +---^--|          | User Input:          User Display: Characters/ |          | Keyboard/Pen/etc        Glyphs on CRT or other |    +-----v---------------+    Representation (e.g. sound) |    | Input Method Editor |                   +------------|-----+    +---------------------+                   | Rendering Engine |        | Input: Any localized/               +---------^--------+        | internationalized      Output: Any localized/ |        | charset                     internationalized |   +----v-----------------+                     charset |   | +------------------+ |                  +----------|-------------+   | | Mail Composition | |                  | +--------------+       |   | | Interface        | | Sender's         | | Mail Reading |       |   | +------------------+ | MUA              | | Interface    |       |   |    |                 |                  | +--------^-----+       |   |    | Nameprepped ACE |       Receiver's |          | Nameprepped |   |    v                 |              MUA |          | ACE         |   | +-------------+      |                  | +-------------------+  |   | | SMTP Client |      |                  | | POP3/IMAP4 Client |  |   | +-------------+      |                  | +-------------------+  |   +----|-----------------+                  +----------^-------------+        | Nameprepped                                   | Nameprepped        v ACE         Nameprepped       Nameprepped     | ACE     +-------------+  ACE   +------------+  ACE   +-------------------+     | SMTP Server | -----> | Mail Store | -----> | POP3/IMAP4 Server |     +-------------+        +------------+        +-------------------+2.1.1 Interface between User and Input Method EditorFor ASCII characters, input is straightforward: the user types on the keyboard and whichever character that is pressed is sent to the application.However, for international characters, the end-user has to use a script-specific Input Method Editor (IME), which may or may not be built-intothe OS, to interpret what the user communicates to the system andthereafter send the respective international characters to the application.