Internet Draft Paul Hoffman draft-hoffman-iea-headermap-00.txt Internet Mail Consortium February 5, 2003 Expires in six months Display of Internationalized Mail Addresses Through Address Mapping Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Mailbox names often represent the names of human users. Many of these users throughout the world have names that are not normally represented by the users with just the ASCII repertoire of characters, and would therefore like to use their real names in their mailbox names. This protocol describes how mail clients can be enhanced to display mailbox names in non-ASCII characters through the use of a new RFC 2822 header field called "Address-map". 1. Introduction The format of email messages [MSGFMT] only allows ASCII characters in the headers of messages. This prevents users from having email addresses that contain non-ASCII characters. This specification describes a new header field, "Address-map", that allows a mail user agent (MUA) to display mailbox names in non-ASCII characters. In brief, users continue to use mailbox names that are all-ASCII characters, and the structure of those names is unchanged. Sending MUAs can add the Address-map header field to tell the receiving MUA how to display the various mailbox names that appear in the headers of the message. Messages that contain the Address-map header can be displayed without problem by unenhanced MUAs: the mailbox names will simply display as ASCII. 1.1 Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Unless otherwise noted, all terms used here are defined in [MSGFMT]. In this document, a mailbox name is "all-ASCII" if every character in the name is in the ASCII character repertoire [ASCII]; a name is "non-ASCII" if any character is not in the ASCII character repertoire. This document is being discussed on the ietf-imaa mailing list. See <http://www.imc.org/ietf-imaa/> for information about subscribing and the list's archive. 2. Address-map headers When a message creator wants a mailbox name that appears in a header in the message to appear with non-ASCII characters, they add an Address-map header to the message. (Clearly, this function will normally be performed by the MUA because users rarely create their own headers.) The Address-map header contains a list of email addresses and the internationalized mailbox names that they map to. 2.1 Header syntax The structure of the Address-map header is: "Address-map: " mapInstance [ *(";" mapInstance) ] mapInstance = addr-spec "," displayedLHS displayedLHS = <Base64 string> The encoding for mapInstance and displayed-LHS are ASCII. The content of displayed-LHS is the Base64 encoding of the UTF-8 [UTF8] string representing the characters that are meant to be displayed for the mailbox name. Note that address maps only map internationalized mailbox names, not internationalized domain names. MUAs that follow this specification MUST use the IDNA specification [IDNA] for handling internationalized domain names. 2.2 Examples A single map for displaying "Jos<eacute>" as the mailbox name in the address "jose@example.com": Address-map: jose@example.com,Sm9zw6k= Two addresses for mapping: Address-map: jose@example.com,Sm9zw6k=;yuji@example.com,44KG44GY An address map for a mailbox that has an internationalized domain name of "<iacute>dn.com": Address-map: jose@xn--dn-mja.com,Sm9zw6k= 3. Use of mapping by MUAs When an MUA that follows this specification displays a message to a user, it first checks whether there is an Address-map header. If so, the MUA sees whether any of the mappings in the head exist in any other header field that uses the addr-spec syntax. If matches are found, the MUA uses the information in the mapInstance part of a mapping to determine how to display the address to the user. Note that even though the mapInstance is a Base64 encoding of a UTF-8 string, the MUA is not forced to display the name in UTF-8. For example, if the native character set of the MUA is UTF-16, GB2312, and so on, the MUA will convert the Unicode characters mapInstance to the equivalent characters in the target character set. Clearly, users of enhanced MUAs will expect to be able to enter mailbox names in the native scripts. Therefore, MUAs that follow this specification SHOULD keep mappings in their address book function. Similarly, MUAs that follow this specification MUST be able to add Address-map headers to outgoing mail messages. 4. Security considerations If a user has a non-ASCII mailbox address and a mapped all-ASCII mailbox address, a digital certificate that identifies that user SHOULD have both addresses in the identity. Having multiple email addresses as identities in a single certificate is already supported in PKIX and OpenPGP. 5. IANA considerations If IANA had a registry for header fields, it would need to add Address-map. However, no such registry exists at the current time. 6. References 6.1 Normative references [ASCII] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969. [IDNA] Faltstrom, P., et. al., "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MSGFMT] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [UTF8] Yergeau, F. "UTF-8, a Transformation Format of ISO 10646", RFC 3629, November 2003. 7. Author's address Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA phoffman@imc.org 8. Open issues - Need to figure out where there should be MUSTs and SHOULDs. - Need to think more about other places that the maps can and cannot be used.