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

The list of Internet-Draft Shadow Directories can be accessed at


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

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
<> 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 "":


Two addresses for mapping:


An address map for a mailbox that has an internationalized domain
name of "<iacute>":


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

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

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.