idnits 2.17.1 draft-yeh-ima-utf8headers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (September 27, 2005) is 6783 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) == Unused Reference: 'ASCII' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC3490' is defined on line 325, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-02) exists of draft-yao-ima-smtpext-00 -- Possible downref: Normative reference to a draft: ref. 'IMA-SMTP-extension' -- Possible downref: Non-RFC (?) normative reference: ref. 'IMA-overview' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yeh, Ed. 3 Internet-Draft TWNIC 4 Expires: March 31, 2006 September 27, 2005 6 Transmission of Email Headers in UTF-8 Encoding 7 draft-yeh-ima-utf8headers-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 31, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Full internationalization of electronic mail requires not only the 41 capability to transmit non-ASCII content, to encode selected 42 information in specific header fields, and to use international 43 characters in envelope addresses. It also requires being able to 44 express those addresses and information based on them in mail 45 headers. This document specifies the use of Unicode encoded in 46 UTF-8, rather than ASCII, as the base form for Internet email 47 headers. This form is permitted in transmission only if authorized 48 by an SMTP extension, as specified in an associated specification. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 54 1.2. Background and History . . . . . . . . . . . . . . . . . . 3 55 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Changes to MUAs and to the user's mail environment . . . . . . 4 57 2.1. Changes to MUA sending . . . . . . . . . . . . . . . . . . 4 58 2.2. Changes to MUA receiving . . . . . . . . . . . . . . . . . 5 59 3. Changes to SMTP Servers and Clients . . . . . . . . . . . . . 5 60 3.1. Impact on Message Headers . . . . . . . . . . . . . . . . 5 61 3.2. Things not changed from RFC 2822 . . . . . . . . . . . . . 6 62 3.3. Additional processing rules . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 Intellectual Property and Copyright Statements . . . . . . . . . . 10 72 1. Introduction 74 1.1. Role of this specification 76 Full internationalization of electronic mail requires several 77 capabilities: 79 o The capability to transmit non-ASCII content, provided for as part 80 of the basic MIME specification [RFC2045], [RFC2046]. 81 o The capability to encode selected information in specific header 82 fields, provided for as another part of the MIME specification 83 [RFC2047]. 84 o The capability to use international characters in envelope 85 addresses, discussed in [IMA-overview] and specified in [IMA-SMTP- 86 extension]. And, finally, 87 o The capability to express those addresses, and information related 88 to and based on them, in mail headers, defined in this document. 90 This document specifies the use of Unicode encoded in UTF-8 91 [RFC3629], rather than ASCII, as the base form for Internet email 92 headers. This form is permitted in transmission, if and only if 93 authorized by the SMTP extension specified in [IMA-SMTP-extension]. 95 1.2. Background and History 97 Mailbox names often represent the names of human users. Many of 98 these users throughout the world have names that are not normally 99 represented with just the ASCII repertoire of characters, and would 100 more the less like to use their real names in their mailbox names. 101 These users are also likely to use non-ASCII text in their common 102 names and subjects of email messages, both in what they send and what 103 they receive. This protocol specifies UTF-8 as the encoding to 104 represent email header messages. 106 The traditional format of email messages [RFC2822] only allows ASCII 107 characters in the headers of messages. This prevents users from 108 having email addresses that contain non-ASCII characters. It further 109 forces non-ASCII text in common names, comments, and in free text 110 (such as in the Subject: field) to be in quoted-printable format 111 [RFC2047]. This specification describes a change to the email 112 message format that is connected to the SMTP message transport change 113 described in the associated specifications [IMA-overview] and [IMA- 114 SMTP-extension], and that allows non-ASCII characters throughout 115 email headers. These changes affect SMTP clients, SMTP servers, and 116 mail user agents (MUAs). 118 As specified in [IMA-SMTP-extension], an SMTP protocol extension 119 [RFC2821] is used to prevent the transmission of messages with UTF-8 120 headers to systems that cannot handle such messages. 122 Use this SMTP extension helps prevent against the introduction of 123 such messages into message stores that might misrepresent or mangle 124 such messages. It should be noted that using an ESMTP extension does 125 not prevent against transferring email messages with UTF-8 headers to 126 other systems that use the email format for messages and that may not 127 be upgraded, such as the POP and IMAP protocols. Those protocols 128 will need to be changed in order to handle stored messages that have 129 UTF-8 headers. 131 The objective for this protocol is to allow UTF-8 everywhere in the 132 headers. Issues about how to handle messages that contain UTF-8 133 headers but are proposed to be delivered to systems that have not 134 been upgraded to support this capability are discussed elsewhere, 135 particularly in [IMA-downgrading]. 137 This protocol is workable even if IMA mailbox names are not 138 presented. For example, the protocol might still be used if just the 139 subject header has non-ASCII characters, but the protocol MUST be 140 used if other headers (particularly trace headers such as 141 "Received:") contain non-ASCII characters. 143 1.3. Terminology 145 In this document, headers are "UTF-8 header" if the bodies of headers 146 contain UTF-8 characters. 148 Unless otherwise noted, all terms used here are defined in [RFC2821] 149 or [RFC2822] or in [IMA-overview]. 151 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 152 and "MAY" in this document are to be interpreted as described in RFC 153 2119 [RFC2119]. 155 This document is being discussed on the ima mailing list. See 156 https://www1.ietf.org/mailman/listinfo/ima for information about 157 subscribing. The list's archive is at 158 http://www1.ietf.org/mail-archive/web/ima/index.html. 160 2. Changes to MUAs and to the user's mail environment 162 2.1. Changes to MUA sending 164 Sending MUAs that follow this protocol MUST create all headers 165 encoded in UTF-8. No other direct encodings are allowed. MUAs MAY 166 continue to use quoted-printable text to specify some text in other 167 encodings; however this is not recommended because it is likely that 168 this will not interoperate well with MUAs that follow this 169 specification. 171 2.2. Changes to MUA receiving 173 Receiving MUAs that follow this protocol MUST able to handle email 174 headers encoded in UTF-8. Which means that the email fetching 175 prototol such as POP3 or IMAP MAY need to be updated. 177 3. Changes to SMTP Servers and Clients 179 The use of UTF-8 headers is dependent on the use of an SMTP extension 180 named "IMA". 182 That protocol is defined in [IMA-SMTP-extension]. If that extension 183 is not supported, UTF-8 headers MUST NOT be transmitted. 185 3.1. Impact on Message Headers 187 If an SMTP server advertises the IMA extension, an SMTP client that 188 supports this protocol SHOULD send message headers as described in 189 this document. 191 The final delivery SMTP server is responsible for knowing whether the 192 message store can handle UTF-8 headers or not. A terminal SMTP 193 server MUST NOT advertise the IMA extension if the message store 194 cannot handle UTF-8 headers. 196 If an SMTP client see the IMA extension advertised by an SMTP server, 197 the SMTP client MUST send all header message in UTF-8. However, the 198 Message-ID is the unique identifier of a single email. In order to 199 maintain the identity, message identifiers of the Message-ID fields 200 MUST be created in all ASCII. Also when In-Reply-To or Reference are 201 presented in email header, the Message-ID in these header fields MUST 202 be created in all ASCII. 204 If an SMTP client does not see the IMA extension advertised by an 205 SMTP server, the SMTP client MAY either 207 o Downgrade the non-ASCII contents of all header bodies before 208 continuing to send the message, as described in [IMA-downgrading]. 209 The SMTP client SHOULD send the message with the downgraded header 210 bodies as a normal message. 211 o Reject the message with a reply code of 558. If any header body 212 cannot be downgraded, this second option MUST be chosen. 214 3.2. Things not changed from RFC 2822 216 Note that this protocol does change the definition of header field 217 names. That is, only the bodies of headers are allowed to have non- 218 ASCII characters; the rules in RFC 2822 for header names are not 219 changed. 221 Similarly, this protocol does not change the date and time 222 specification in RFC 2822. 224 3.3. Additional processing rules 226 In order to make mail retrieval easier, final delivery SMTP servers 227 SHOULD write messages addressed to either the non-ASCII address or 228 the all-ASCII address into the same mailbox. However, given that 229 this is quite different than common practice today, the ramifications 230 for doing this should be studied carefully before this is 231 implemented. 233 4. Security Considerations 235 If a user has a non-ASCII mailbox address and a all-ASCII mailbox 236 address, a digital certificate that identifies that user SHOULD have 237 both addresses in the identity. Having multiple email addresses as 238 identities in a single certificate is already supported in PKIX and 239 OpenPGP. 241 Because UTF-8 often requires several octets to encode a single 242 character, internationalized local parts may cause mail addresses to 243 become longer. Then may possibly make it harder to keep lines in a 244 header under 78 characters. Lines that are longer than 78 characters 245 (which is a SHOULD specification, not a MUST specification, in RFC 246 2822) could possibly cause mail user agents to fail in ways that 247 affect security. 249 5. IANA considerations 251 The ESMTP extension needed to support this specification is specified 252 in [IMA-SMTP-extension]. This specification does not require any 253 additional IANA actions in that regard. 255 6. Acknowledgements 257 This document was created by incorporating a good deal of material 258 from an old Internet Draft by Paul Hoffman [Hoffman-utf8-headers]. 260 While many of the concepts and details have changed, the 261 contributions from that draft are greatly appreciated. 263 Most of the content of this document is provided by John C Klensin. 264 Also some significant comments and suggestions were received from 265 Yangwoo KO, Yoshiro YONEYA, and other members of the JET team and 266 were incorporated into the document. The editor is much great thanks 267 to their contribution sincerely. 269 7. References 271 7.1. Normative References 273 [ASCII] American National Standards Institute (formerly United 274 States of America Standards Institute), "USA Code for 275 Information Interchange", ANSI X3.4-1968, 1968. 277 ANSI X3.4-1968 has been replaced by newer versions with 278 slight modifications, but the 1968 version remains 279 definitive for the Internet. 281 [IMA-SMTP-extension] 282 Yao, J., Ed., "SMTP extension for internationalized email 283 address", draft-yao-ima-smtpext-00.txt (work in progress), 284 September 2005. 286 [IMA-overview] 287 "Overview and Framework of Internationalized Email Address 288 Delivery", 2005. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 294 April 2001. 296 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 297 April 2001. 299 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 300 10646", STD 63, RFC 3629, November 2003. 302 7.2. Informative References 304 [Hoffman-utf8-headers] 305 Hoffman, P., "SMTP Service Extensions or Transmission of 306 Headers in UTF-8 Encoding", 307 draft-hoffman-utf8headers-00.txt (work in progress), 308 December 2003. 310 [IMA-downgrading] 311 "whatever we call the downgrading document", 2005. 313 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 314 Extensions (MIME) Part One: Format of Internet Message 315 Bodies", RFC 2045, November 1996. 317 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 318 Extensions (MIME) Part Two: Media Types", RFC 2046, 319 November 1996. 321 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 322 Part Three: Message Header Extensions for Non-ASCII Text", 323 RFC 2047, November 1996. 325 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 326 "Internationalizing Domain Names in Applications (IDNA)", 327 RFC 3490, March 2003. 329 Author's Address 331 Jeff Yeh (editor) 332 TWNIC 333 4F-2, No. 9, Sec 2, Roosvelt Rd. 334 Taipei, 100 335 Taiwan 337 Phone: +886 2 23411313 ext 506 338 Email: jeff@twnic.net.tw 340 Intellectual Property Statement 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 364 Disclaimer of Validity 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Copyright Statement 376 Copyright (C) The Internet Society (2005). This document is subject 377 to the rights, licenses and restrictions contained in BCP 78, and 378 except as set forth therein, the authors retain all their rights. 380 Acknowledgment 382 Funding for the RFC Editor function is currently provided by the 383 Internet Society.