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.