idnits 2.17.1
draft-hoffman-iea-headermap-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 194 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 5, 2003) is 7744 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 3490 (ref. 'IDNA') (Obsoleted by RFC
5890, RFC 5891)
** Obsolete normative reference: RFC 2822 (ref. 'MSGFMT') (Obsoleted by RFC
5322)
Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Paul Hoffman
2 draft-hoffman-iea-headermap-00.txt Internet Mail Consortium
3 February 5, 2003
4 Expires in six months
6 Display of Internationalized Mail Addresses
7 Through Address Mapping
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note
16 that other groups may also distribute working documents as
17 Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six
20 months and may be updated, replaced, or obsoleted by other documents
21 at any time. It is inappropriate to use Internet-Drafts as
22 reference material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 Abstract
32 Mailbox names often represent the names of human users. Many of these
33 users throughout the world have names that are not normally represented
34 by the users with just the ASCII repertoire of characters, and would
35 therefore like to use their real names in their mailbox names. This
36 protocol describes how mail clients can be enhanced to display mailbox
37 names in non-ASCII characters through the use of a new RFC 2822 header
38 field called "Address-map".
40 1. Introduction
42 The format of email messages [MSGFMT] only allows ASCII characters in
43 the headers of messages. This prevents users from having email addresses
44 that contain non-ASCII characters. This specification describes a new
45 header field, "Address-map", that allows a mail user agent (MUA) to
46 display mailbox names in non-ASCII characters.
48 In brief, users continue to use mailbox names that are all-ASCII
49 characters, and the structure of those names is unchanged. Sending MUAs
50 can add the Address-map header field to tell the receiving MUA how to
51 display the various mailbox names that appear in the headers of the
52 message. Messages that contain the Address-map header can be displayed
53 without problem by unenhanced MUAs: the mailbox names will simply
54 display as ASCII.
56 1.1 Terminology
58 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
59 "MAY" in this document are to be interpreted as described in RFC 2119
60 [KEYWORDS].
62 Unless otherwise noted, all terms used here are defined in [MSGFMT].
64 In this document, a mailbox name is "all-ASCII" if every character in
65 the name is in the ASCII character repertoire [ASCII]; a name is
66 "non-ASCII" if any character is not in the ASCII character repertoire.
68 This document is being discussed on the ietf-imaa mailing list. See
69 for information about subscribing and
70 the list's archive.
72 2. Address-map headers
74 When a message creator wants a mailbox name that appears in a header in
75 the message to appear with non-ASCII characters, they add an Address-map
76 header to the message. (Clearly, this function will normally be
77 performed by the MUA because users rarely create their own headers.) The
78 Address-map header contains a list of email addresses and the
79 internationalized mailbox names that they map to.
81 2.1 Header syntax
83 The structure of the Address-map header is:
85 "Address-map: " mapInstance [ *(";" mapInstance) ]
87 mapInstance = addr-spec "," displayedLHS
89 displayedLHS =
91 The encoding for mapInstance and displayed-LHS are ASCII. The content of
92 displayed-LHS is the Base64 encoding of the UTF-8 [UTF8] string
93 representing the characters that are meant to be displayed for the
94 mailbox name.
96 Note that address maps only map internationalized mailbox names, not
97 internationalized domain names. MUAs that follow this specification
98 MUST use the IDNA specification [IDNA] for handling internationalized
99 domain names.
101 2.2 Examples
103 A single map for displaying "Jos" as the mailbox name in the
104 address "jose@example.com":
106 Address-map: jose@example.com,Sm9zw6k=
108 Two addresses for mapping:
110 Address-map: jose@example.com,Sm9zw6k=;yuji@example.com,44KG44GY
112 An address map for a mailbox that has an internationalized domain
113 name of "dn.com":
115 Address-map: jose@xn--dn-mja.com,Sm9zw6k=
117 3. Use of mapping by MUAs
119 When an MUA that follows this specification displays a message to a
120 user, it first checks whether there is an Address-map header. If so, the
121 MUA sees whether any of the mappings in the head exist in any other
122 header field that uses the addr-spec syntax. If matches are found, the
123 MUA uses the information in the mapInstance part of a mapping to
124 determine how to display the address to the user.
126 Note that even though the mapInstance is a Base64 encoding of a UTF-8
127 string, the MUA is not forced to display the name in UTF-8. For example,
128 if the native character set of the MUA is UTF-16, GB2312, and so on, the
129 MUA will convert the Unicode characters mapInstance to the equivalent
130 characters in the target character set.
132 Clearly, users of enhanced MUAs will expect to be able to enter mailbox
133 names in the native scripts. Therefore, MUAs that follow this
134 specification SHOULD keep mappings in their address book function.
135 Similarly, MUAs that follow this specification MUST be able to add
136 Address-map headers to outgoing mail messages.
138 4. Security considerations
140 If a user has a non-ASCII mailbox address and a mapped all-ASCII mailbox
141 address, a digital certificate that identifies that user SHOULD have
142 both addresses in the identity. Having multiple email addresses as
143 identities in a single certificate is already supported in PKIX and
144 OpenPGP.
146 5. IANA considerations
148 If IANA had a registry for header fields, it would need to add Address-map.
149 However, no such registry exists at the current time.
151 6. References
153 6.1 Normative references
155 [ASCII] Cerf, V., "ASCII format for Network Interchange", RFC 20,
156 October 1969.
158 [IDNA] Faltstrom, P., et. al., "Internationalizing Domain Names in
159 Applications (IDNA)", RFC 3490, March 2003.
161 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
162 Requirement Levels", BCP 14, RFC 2119, March 1997.
164 [MSGFMT] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
166 [UTF8] Yergeau, F. "UTF-8, a Transformation Format of ISO 10646", RFC
167 3629, November 2003.
169 7. Author's address
171 Paul Hoffman
172 Internet Mail Consortium
173 127 Segre Place
174 Santa Cruz, CA 95060 USA
175 phoffman@imc.org
177 8. Open issues
179 - Need to figure out where there should be MUSTs and SHOULDs.
181 - Need to think more about other places that the maps can and cannot
182 be used.