idnits 2.17.1 draft-ietf-eai-rfc5335bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-eai-rfc5335bis-09', but the file name used is 'draft-ietf-eai-rfc5335bis-10' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5335, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5321, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5322, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2045, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2045, updated by this document, for RFC5378 checks: 1994-06-16) -- 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 (March 15, 2011) is 4785 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) == Missing Reference: 'RFC2821' is mentioned on line 537, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) == Missing Reference: 'RFC2822' is mentioned on line 537, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'RFC5504' is mentioned on line 541, but not defined ** Obsolete undefined reference: RFC 5504 (Obsoleted by RFC 6530) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-12) exists of draft-ietf-eai-frmwrk-4952bis-10 == Outdated reference: A later version (-16) exists of draft-ietf-eai-rfc5336bis-07 == Outdated reference: A later version (-08) exists of draft-ietf-eai-rfc5721bis-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'NFC' ** Downref: Normative reference to an Informational RFC: RFC 5598 -- Obsolete informational reference (is this intentional?): RFC 1652 (Obsoleted by RFC 6152) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization Y. Abel 3 (EAI) TWNIC 4 Internet-Draft S. Steele 5 Obsoletes: 5335 (if approved) Microsoft 6 Updates: 2045,5321,5322 March 15, 2011 7 (if approved) 8 Intended status: Standards Track 9 Expires: September 16, 2011 11 Internationalized Email Headers 12 draft-ietf-eai-rfc5335bis-09 14 Abstract 16 Internet mail was originally limited to 7-bit ASCII. Recent 17 enhancements support Unicode's UTF-8 encoding in portions of a 18 message. Full internationalization of electronic mail requires 19 additional enhancement, including support for UTF-8 in user-oriented 20 header fields, such as in the To, From, and Subject fields. This 21 document specifies an enhancement to Internet mail that permits 22 native UTF-8 support in the header and body of a message. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 16, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Brief Overview of Changes . . . . . . . . . . . . . . . . 3 60 2. Relation to Other Standards . . . . . . . . . . . . . . . . . 3 61 3. Background and History . . . . . . . . . . . . . . . . . . . . 4 62 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 64 5.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5 65 5.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 6 66 5.3. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 6 67 5.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8 68 5.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9 69 5.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. draft-ietf-eai-rfc5335bis-00 . . . . . . . . . . . . . . . 12 75 9.2. draft-ietf-eai-rfc5335bis-01 . . . . . . . . . . . . . . . 12 76 9.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 12 77 9.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 13 78 9.5. draft-ietf-eai-rfc5335bis-04 . . . . . . . . . . . . . . . 13 79 9.6. draft-ietf-eai-rfc5335bis-05 . . . . . . . . . . . . . . . 13 80 9.7. draft-ietf-eai-rfc5335bis-06 . . . . . . . . . . . . . . . 13 81 9.8. draft-ietf-eai-rfc5335bis-07 . . . . . . . . . . . . . . . 13 82 9.9. draft-ietf-eai-rfc5335bis-09 . . . . . . . . . . . . . . . 13 83 9.10. draft-ietf-eai-rfc5335bis-10 . . . . . . . . . . . . . . . 13 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Appendix A. Changes to support UTF-8 . . . . . . . . . . . . . . 15 89 1. Introduction 91 Internet mail distinguishes a message from its transport and further 92 divides a message between a header and a body [RFC5598]. Internet 93 mail header fields contain a variety of strings that are intended to 94 be user-visible. The range of supported characters for these strings 95 was originally limited to a subset of [ASCII]; globalization of the 96 Internet requires support of the much larger set contained in UTF-8 97 [RFC5198]. Complex encoding alternatives to UTF-8, as an overlay to 98 the existing ASCII base, would introduce inefficiencies as well as 99 opportunities for processing errors. Native support for UTF-8 100 encoding [RFC3629]. is widely available among systems now used over 101 the Internet. Hence supporting this encoding directly within email 102 is desired. This document specifies an enhancement to Internet mail 103 that permits the use of UTF-8 encoding, rather than only ASCII, as 104 the base form for header fields. 106 This specification is based on a model of native, end-to-end support 107 for UTF-8, which uses an "8-bit clean" environment . Support for 108 carriage across legacy, 7-bit infrastructure and for processing by 109 7-bit receivers requires additional mechanisms that are not provided 110 by this specification. 112 1.1. Brief Overview of Changes 114 This document updates email header [RFC5322] and MIME header 115 [RFC2045]. Email header value extends beyond ASCII, allowing UTF-8 116 encoding. MIME header lifts the prohibition against using content- 117 transfer-encoding on all subtypes under composite-type "message/". 118 Appendix A documents the derived ABNF rules that inherit support 119 UTF-8, due to the update of ABNF introduces from this document. 121 [Editor notes will be removed before Last Call] 123 [Editor Note 1: This revision (-08 and up) changed the ABNF approach 124 compared to previous revision (-07 and before). ] 126 [Editor Note 2: pending -- ABF to support IDN] 128 [Editor Note 3: Discuss with WG whether some fields, like Trace 129 header, have issues if UTF-8 encoding allowed in values] 131 2. Relation to Other Standards 133 This document updates Section 6.4 of [RFC2045]. It removes the 134 blanket ban on applying a content-transfer-encoding to all subtypes 135 of message/ and instead specifies that a composite subtype MAY 136 specify whether or not a content-transfer-encoding can be used for 137 that subtype, with "cannot be used" as the default. 139 This document also updates Section 3.4 of [RFC5322]. It Extended 140 mailbox address syntax to permit UTF-8 character in Section 5.3. 142 Allowing use of a content-transfer-encoding on subtypes of messages 143 is not limited to transmissions that are authorized by the SMTP 144 extension specified in [I-D.ietf-eai-rfc5336bis]. message/global (see 145 Section 5.6) of this document permits use of a content-transfer- 146 encoding. 148 3. Background and History 150 Mailbox names often represent the names of human users. Many of 151 these users throughout the world have names that are not normally 152 expressed with just the ASCII repertoire of characters, and would 153 like to use more or less their real names in their mailbox names. 154 These users are also likely to use non-ASCII text in their display 155 names and subjects of email messages, both received and sent. This 156 protocol specifies UTF-8 as the encoding to represent email header 157 field bodies. 159 The traditional format of email messages [RFC5322] allows only ASCII 160 characters in the header fields of messages. This prevents users 161 from having email addresses that contain non-ASCII characters. It 162 further forces non-ASCII text in display names, comments, and in free 163 text (such as in the "Subject:" field) to be encoded (as required by 164 MIME format [RFC2047]). This specification describes a change to the 165 email message format that is related to the SMTP message transport 166 change described in the associated documents 167 [I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5336bis], and that 168 allows non-ASCII characters in most email header fields. These 169 changes affect SMTP clients, SMTP servers, mail user agents (MUAs), 170 list expanders, gateways to other media, and all other processes that 171 parse or handle email messages. 173 As specified in [I-D.ietf-eai-rfc5336bis], an SMTP protocol extension 174 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 175 header fields to systems that cannot handle such messages. 177 Use of this SMTP extension helps prevent the introduction of such 178 messages into message stores that might misinterpret, improperly 179 display, or mangle such messages. It should be noted that using an 180 ESMTP extension does not prevent transferring email messages with 181 UTF-8 header fields to other systems that use the email format for 182 messages and that may not be upgraded, such as unextended POP and 183 IMAP servers. Changes to these protocols to handle UTF-8 header 184 fields are addressed in [I-D.ietf-eai-rfc5721bis] and 186 [I-D.ietf-eai-5378bis]. 188 The objective for this protocol is to allow UTF-8 in email header 189 fields. 191 4. Terminology 193 A plain ASCII string is fully compatible with [RFC5321] and 194 [RFC5322]. In this document, non-ASCII strings are UTF-8 strings if 195 they are in header which contain at least one . 197 Unless otherwise noted, all terms used here are defined in [RFC5321], 198 [RFC5322], [I-D.ietf-eai-frmwrk-4952bis], or 199 [I-D.ietf-eai-rfc5336bis]. 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in [RFC2119]. 205 5. Changes on Message Header Fields 207 SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP 208 extension is advertised by the SMTP server or is permitted by other 209 transport mechanisms. 211 This protocol does NOT change the [RFC5322] rules for defining header 212 field names. The bodies of header fields are allowed to contain 213 UTF-8 characters, but the header field names themselves must contain 214 only ASCII characters. 216 To permit UTF-8 characters in field values, the header definition in 217 [RFC5322] is extended to support the new format. The following ABNF 218 is defined to substitute those definitions in [RFC5322]. 220 The syntax rules not covered in this section remain as defined in 221 [RFC5322]. 223 5.1. UTF-8 Syntax and Normalization 225 UTF-8 characters can be defined in terms of octets using the 226 following ABNF [RFC5234], taken from [RFC3629]: 228 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 230 UTF8-2 = 232 UTF8-3 = 233 UTF8-4 = 235 See [RFC5198] for a discussion of normalization; the use of 236 normalization form [NFC] is RECOMMENDED. Actually, if one is going 237 to do internationalization properly, one of the most often-cited 238 goals is to permit people to spell their names correctly. Since many 239 mailbox local parts reflect personal names, that principle applies as 240 well. And NFKC is not recommended because it may lose information 241 that is needed to correctly spell some names in unusual 242 circumstances. 244 5.2. Changes on MIME Headers 246 This specification updates Section 6.4 of [RFC2045]. [RFC2045] 247 prohibits applying a content-transfer-encoding to any subtypes of 248 "message/". This specification relaxes the rule -- it allows newly 249 defined MIME types to permit content-transfer-encoding, and it allows 250 content-transfer-encoding for message/global (see Section 5.6). 252 Background: Normally, transfer of message/global will be done in 253 8-bit-clean channels, and body parts will have "identity" encodings, 254 that is, no decoding is necessary. In the case where a message 255 containing a message/global is downgraded from 8-bit to 7-bit as 256 described in [RFC1652], an encoding may be applied to the message; if 257 the message travels multiple times between a 7-bit environment and an 258 environment implementing UTF8SMTP, multiple levels of encoding may 259 occur. This is expected to be rarely seen in practice, and the 260 potential complexity of other ways of dealing with the issue are 261 thought to be larger than the complexity of allowing nested encodings 262 where necessary. 264 5.3. Syntax Extensions to RFC 5322 266 The following rules are intended to extend the corresponding rules in 267 [RFC5322] in order to allow UTF-8 characters. 269 FWS = 271 CFWS = 273 ctext =/ UTF8-non-ascii 274 ; Extending ctext in RFC 5322, Section 3.2.2 275 comment = "(" *([FWS] uCcontent) [FWS] ")" 277 word = uAtom / uQuoted-String 279 This means that all the [RFC5322] constructs that build upon these 280 will permit UTF-8 characters, including comments and quoted strings. 281 We do not change the syntax of in order to allow UTF-8 282 characters in . This would also allow UTF-8 characters in 283 , which is not allowed due to the limitation described in 284 Section 5.5. Instead, is added to meet this requirement. 286 uText = %d1-9 / ; all UTF-8 characters except 287 %d11-12 / ; US-ASCII NUL, CR, and LF 288 %d14-127 / 289 UTF8-non-ascii 291 uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp 293 VCHAR = 295 WSP = 297 obs-qp = 299 uQcontent = uQtext / uQuoted-Pair 301 DQUOTE = 303 uCcontent = ctext / uQuoted-Pair / comment 305 uQtext = qtext / UTF8-non-ascii 307 uAtext = ALPHA / DIGIT / 308 "!" / "#" / ; Any character except 309 "$" / "%" / ; controls, SP, and specials. 310 "&" / "'" / ; Used for atoms. 311 "*" / "+" / 312 "-" / "/" / 313 "=" / "?" / 314 "^" / "_" / 315 "`" / "{" / 316 "|" / "}" / 317 "~" / 318 UTF8-non-ascii 320 uAtom = [CFWS] 1*uAtext [CFWS] 322 uDot-Atom = [CFWS] uDot-Atom-text [CFWS] 324 uDot-Atom-text = 1*uAtext *("." 1*uAtext) 326 To allow the use of UTF-8 in a Content-Description header field 328 [RFC2045], the following syntax is used: 330 description = "Content-Description" ":" *uText 331 ; Replace description in RFC 2045, Section 8 333 The syntax is extended above to allow UTF-8 in all 334 header fields. 336 Note, however, this does not remove any constraint on the character 337 set of protocol elements; for instance, all the allowed values for 338 timezone in the "Date:" header fields are still expressed in ASCII. 339 And also, none of this revised syntax changes what is allowed in a 340 , which will still remain in pure ASCII. 342 5.4. Change on addr-spec Syntax 344 Internationalized email addresses are represented in UTF-8. Thus, 345 all header fields containing es are updated from [RFC5321] 346 Section 4.1.2 to permit UTF-8 addresses. 348 mailbox = name-addr / addr-spec / uAddr-Spec 349 ; Replace mailbox in RFC 5322, Section 3.4 351 angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS] 352 ; Extending angle-addr in RFC 5322, Section 3.4 354 uAddr-Spec = uLocal-Part "@" uDomain 356 uLocal-Part = uDot-Atom / uQuoted-String / obs-local-part 357 ; Replace Local-Part in RFC 5322, Section 3.4.1 359 uQuoted-String = [CFWS] DQUOTE *([FWS] uQcontent) [FWS] DQUOTE [CFWS] 361 obs-local-part = 362 uDomain = uDot-Atom / domain-literal / obs-domain 364 domain-literal = 366 Below are a few examples of possible representations. 368 "DISPLAY_NAME" 369 ; traditional mailbox format 371 "DISPLAY_NAME" 372 ; message will be rejected if UTF8SMTP extension is not supported 374 375 ; without DISPLAY_NAME and quoted string 376 ; message will be rejected if UTF8SMTP extension is not supported 378 5.5. Trace Field Syntax 380 The 'uFor' clause in "Received:" fields has been allowed the use of 381 internationalized addresses in "For" fields. It is described in 382 [I-D.ietf-eai-rfc5336bis], Section 3.6.3. 384 The "Return-path" designates the address to which messages indicating 385 non-delivery or other mail system failures are to be sent. Thus, the 386 header is augmented to carry UTF-8 addresses (see the revised syntax 387 of in Section 5.4 of this document). This will not 388 break the rule of trace field integrity, because the header field is 389 added at the last MTA and described in [RFC5321]. 391 The on "Received:" field ( described in Section 392 3.6.7 of [RFC5322]) syntax is augmented to allow UTF-8 email address 393 in the "For" field. is augmented to include UTF-8 email 394 address. In order to allow UTF-8 email addresses in an , 395 is added to . 397 received-token =/ uAddr-Spec 399 5.6. message/global 401 Internationalized messages MUST only be transmitted as authorized by 402 [I-D.ietf-eai-rfc5336bis] or within a non-SMTP environment that 403 supports these messages. A message is a "message/global message", if 405 o it contains UTF-8 header values as specified in this document, or 407 o it contains UTF-8 values in the headers fields of body parts. 409 The type message/global is similar to message/rfc822, except that it 410 specifies that a message can contain UTF-8 characters in the headers 411 of the message or body parts. If this type is sent to a 7-bit-only 412 system, it has to be encoded in MIME [RFC2045]. (Note that a system 413 compliant with MIME that doesn't recognize message/global SHOULD 414 treat it as "application/octet-stream" as described in Section 5.2.4 415 of [RFC2046].) 417 Type name: message 419 Subtype name: global 421 Required parameters: none 423 Optional parameters: none 425 Encoding considerations: Any content-transfer-encoding is permitted. 426 The 8-bit or binary content-transfer-encodings are recommended 427 where permitted. 429 Security considerations: See Section 6. 431 Interoperability considerations: The media type provides 432 functionality similar to the message/rfc822 content type for email 433 messages with international email headers. When there is a need 434 to embed or return such content in another message, there is 435 generally an option to use this media type and leave the content 436 unchanged or down-convert the content to message/rfc822. Both of 437 these choices will interoperate with the installed base, but with 438 different properties. Systems unaware of internationalized 439 headers will typically treat a message/global body part as an 440 unknown attachment, while they will understand the structure of a 441 message/rfc822. However, systems that understand message/global 442 will provide functionality superior to the result of a down- 443 conversion to message/rfc822. The most interoperable choice 444 depends on the deployed software. 446 Published specification: RFC XXXX 448 Applications that use this media type: SMTP servers and email 449 clients that support multipart/report generation or parsing. 450 Email clients that forward messages with international headers as 451 attachments. 453 Additional information: 455 Magic number(s): none 457 File extension(s): The extension ".u8msg" is suggested. 459 Macintosh file type code(s): A uniform type identifier (UTI) of 460 "public.utf8-email-message" is suggested. This conforms to 461 "public.message" and "public.composite-content", but does not 462 necessarily conform to "public.utf8-plain-text". 464 Person & email address to contact for further information: See the 465 Author's Address section of this document. 467 Intended usage: COMMON 469 Restrictions on usage: This is a structured media type that embeds 470 other MIME media types. The 8-bit or binary content-transfer- 471 encoding SHOULD be used unless this media type is sent over a 472 7-bit-only transport. 474 Author: See the Author's Address section of this document. 476 Change controller: IETF Standards Process 478 6. Security Considerations 480 If a user has a non-ASCII mailbox address and an ASCII mailbox 481 address, a digital certificate that identifies that user may have 482 both addresses in the identity. Having multiple email addresses as 483 identities in a single certificate is already supported in PKIX 484 (Public Key Infrastructure for X.509 Certificates) [RFC5280] and 485 OpenPGP [RFC3156]. 487 Because UTF-8 often requires several octets to encode a single 488 character, internationalized local parts and header value may cause 489 mail addresses to become longer. As specified in [RFC5322], each 490 line of characters MUST be no more than 998 octets, excluding the 491 CRLF. On the other hand, MDA (Mail Delivery Agent) processes that 492 parse, store, or handle email addresses or local parts must take 493 extra care not to overflow buffers, truncate addresses, or exceed 494 storage allotments. Also, they must take care, when comparing, to 495 use the entire lengths of the addresses. 497 There are lots of ways of using UTF-8 to represent something 498 equivalent or similar to a particular displayed character or group of 499 characters, then filtering systems can be bypassed by using one of 500 the variants to avoid detection while still reaching the end user 501 with largely the same original effect. This normalization is 502 described in Section 5.1. 504 The security impact of UTF-8 headers on email signature systems such 505 as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is 506 discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14. 508 7. IANA Considerations 510 IANA is requested to update the registration of the message/global 511 MIME type using the registration form contained in Section 5.6. 513 8. Acknowledgements 515 This document incorporates many ideas first described in Internet- 516 Draft form by Paul Hoffman, although many details have changed from 517 that earlier work. 519 The author especially thanks Jeff Yeh for his efforts and 520 contributions on editing previous versions. 522 Most of the content of this document is provided by John C Klensin. 523 Also, some significant comments and suggestions were received from 524 Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris 525 Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team 526 (Joint Engineering Team) and were incorporated into the document. 527 The editor sincerely thanks them for their contributions. 529 9. Edit history 531 [[RFC Editor: please remove this section before publishing.]] 533 9.1. draft-ietf-eai-rfc5335bis-00 535 1. Applied Errata suggested by Alfred Hoenes. 537 2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322]. 539 3. Abrogate in ABNF of . 541 4. Revoke [RFC5504] from this document. 543 5. Upgrade some references from I-Ds to RFC. 545 9.2. draft-ietf-eai-rfc5335bis-01 547 1. Author name revised. 549 9.3. draft-ietf-eai-rfc5335bis-02 551 1. ABNF revised. 553 9.4. draft-ietf-eai-rfc5335bis-03 555 1. Fix typos 557 2. ABNF revised 559 3. Improve sentence 561 9.5. draft-ietf-eai-rfc5335bis-04 563 1. improve sentences and ABNF revised based on AD and Co-chairs 565 9.6. draft-ietf-eai-rfc5335bis-05 567 1. ABNF revised in Section 5.4 based on AD comments 569 9.7. draft-ietf-eai-rfc5335bis-06 571 1. ABNF revised 573 2. improve Section 7 575 9.8. draft-ietf-eai-rfc5335bis-07 577 1. Minor ABNF revised in Section 5.3 579 2. improve Section 7 581 9.9. draft-ietf-eai-rfc5335bis-09 583 Version -08 was posted in error and withdrawn. Version 09 is is 584 identical to version 07 except for a date change, addition of this 585 note, and some vertical spacing compression on this page. 587 9.10. draft-ietf-eai-rfc5335bis-10 589 1. Add Appendix A and Section 1.1 591 2. Replace polls result in Abstract and Section 1 593 3. Minor Sentence modification 595 10. References 597 10.1. Normative References 599 [ASCII] "Coded Character Set -- 7-bit American 600 Standard Code for Information 601 Interchange", ANSI X3.4, 1986. 603 [I-D.ietf-eai-5378bis] Resnick, P., Newman, C., and S. Shen, 604 "IMAP Support for UTF-8", 605 draft-ietf-eai-5378bis-00 (work in 606 progress), November 2010. 608 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 609 Framework for Internationalized 610 Email", 611 draft-ietf-eai-frmwrk-4952bis-10 (work 612 in progress), September 2010. 614 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 615 for Internationalized Email Address", 616 draft-ietf-eai-rfc5336bis-07 (work in 617 progress), December 2010. 619 [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and 620 K. Fujiwara, "POP3 Support for UTF-8", 621 draft-ietf-eai-rfc5721bis-00 (work in 622 progress), September 2010. 624 [NFC] Davis, M. and K. Whistler, "Unicode 625 Standard Annex #15: Unicode 626 Normalization Forms", September 2010, 627 . 630 [RFC2119] Bradner, S., "Key words for use in 631 RFCs to Indicate Requirement Levels", 632 BCP 14, RFC 2119, March 1997. 634 [RFC3629] Yergeau, F., "UTF-8, a transformation 635 format of ISO 10646", STD 63, 636 RFC 3629, November 2003. 638 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 639 Format for Network Interchange", 640 RFC 5198, March 2008. 642 [RFC5234] Crocker, D. and P. Overell, "Augmented 643 BNF for Syntax Specifications: ABNF", 644 STD 68, RFC 5234, January 2008. 646 [RFC5321] Klensin, J., "Simple Mail Transfer 647 Protocol", RFC 5321, October 2008. 649 [RFC5322] Resnick, P., Ed., "Internet Message 650 Format", RFC 5322, October 2008. 652 [RFC5598] Crocker, D., "Internet Mail 653 Architecture", RFC 5598, July 2009. 655 10.2. Informative References 657 [RFC1652] Klensin, J., Freed, N., Rose, M., 658 Stefferud, E., and D. Crocker, "SMTP 659 Service Extension for 8bit- 660 MIMEtransport", RFC 1652, July 1994. 662 [RFC2045] Freed, N. and N. Borenstein, 663 "Multipurpose Internet Mail Extensions 664 (MIME) Part One: Format of Internet 665 Message Bodies", RFC 2045, 666 November 1996. 668 [RFC2046] Freed, N. and N. Borenstein, 669 "Multipurpose Internet Mail Extensions 670 (MIME) Part Two: Media Types", 671 RFC 2046, November 1996. 673 [RFC2047] Moore, K., "MIME (Multipurpose 674 Internet Mail Extensions) Part Three: 675 Message Header Extensions for Non- 676 ASCII Text", RFC 2047, November 1996. 678 [RFC3156] Elkins, M., Del Torto, D., Levien, R., 679 and T. Roessler, "MIME Security with 680 OpenPGP", RFC 3156, August 2001. 682 [RFC5280] Cooper, D., Santesson, S., Farrell, 683 S., Boeyen, S., Housley, R., and W. 684 Polk, "Internet X.509 Public Key 685 Infrastructure Certificate and 686 Certificate Revocation List (CRL) 687 Profile", RFC 5280, May 2008. 689 Appendix A. Changes to support UTF-8 691 This section provides a basic audit of the places in a message that 692 now can permit UTF-8 rather than being restricted to ASCII, based on 693 the changes to underlying ABNF. The audit ignores rule for 694 "obsolete" constructs in [RFC5322]. (This is a first cut and the 695 list is likely incomplete): 697 VCHAR: quoted-pair, unstructured 699 > ccontent, qcontent 701 > comment, quoted-string 703 > word, local-part 705 > phrase 707 > display-name, keywords 709 ctext: ccontent > comment 711 atext: atom, dot-atom-text 713 qtext: qcontent > quoted-string 715 Authors' Addresses 717 Abel Yang 718 TWNIC 719 4F-2, No. 9, Sec 2, Roosevelt Rd. 720 Taipei, 100 721 Taiwan 723 Phone: +886 2 23411313 ext 505 724 EMail: abelyang@twnic.net.tw 726 Shawn Steele 727 Microsoft 729 EMail: Shawn.Steele@microsoft.com