idnits 2.17.1 draft-ietf-eai-rfc5335bis-06.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2045]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 directly say this. It does mention RFC2045 though, so this could be OK. 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 (December 06, 2010) is 4888 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 520, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) == Missing Reference: 'RFC2822' is mentioned on line 520, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'RFC5504' is mentioned on line 524, but not defined ** Obsolete undefined reference: RFC 5504 (Obsoleted by RFC 6530) == 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' -- Obsolete informational reference (is this intentional?): RFC 1652 (Obsoleted by RFC 6152) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 December 06, 2010 7 (if approved) 8 Intended status: Standards Track 9 Expires: June 9, 2011 11 Internationalized Email Headers 12 draft-ietf-eai-rfc5335bis-06 14 Abstract 16 Full internationalization of electronic mail requires not only the 17 capabilities to transmit non-ASCII content, to encode selected 18 information in specific header fields, and to use non-ASCII 19 characters in envelope addresses. It also requires being able to 20 express those addresses and the information based on them in mail 21 header fields. This document specifies a variant of Internet mail 22 that permits the use of Unicode encoded in UTF-8, rather than ASCII, 23 as the base form for Internet email header field. This form is 24 permitted in transmission only if authorized by an SMTP extension, as 25 specified in an associated specification. This specification updates 26 Section 6.4 of [RFC2045] to conform with the requirements. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 9, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Role of This Specification . . . . . . . . . . . . . . . . 3 64 1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3 65 2. Background and History . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 68 4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5 69 4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 5 70 4.3. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 6 71 4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8 72 4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9 73 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8.1. draft-ietf-eai-rfc5335bis-00 . . . . . . . . . . . . . . . 12 79 8.2. draft-ietf-eai-rfc5335bis-01 . . . . . . . . . . . . . . . 12 80 8.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 12 81 8.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 12 82 8.5. draft-ietf-eai-rfc5335bis-04 . . . . . . . . . . . . . . . 13 83 8.6. draft-ietf-eai-rfc5335bis-05 . . . . . . . . . . . . . . . 13 84 8.7. draft-ietf-eai-rfc5335bis-06 . . . . . . . . . . . . . . . 13 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 1.1. Role of This Specification 93 Full internationalization of electronic mail requires several 94 capabilities: 96 o The capability to transmit non-ASCII content, provided for as part 97 of the basic MIME specification [RFC2045], [RFC2046]. 99 o The capability to use international characters in envelope 100 addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and 101 specified in [I-D.ietf-eai-rfc5336bis]. 103 o The capability to express those addresses, and information related 104 to them and based on them, in mail header fields, defined in this 105 document. 107 This document specifies a variant of Internet mail that permits the 108 use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the 109 base form for Internet email header fields. This form is permitted 110 in transmission, if authorized by the SMTP extension specified in 111 [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of 112 processing it. 114 1.2. Relation to Other Standards 116 This document updates Section 6.4 of [RFC2045]. It removes the 117 blanket ban on applying a content-transfer-encoding to all subtypes 118 of message/ and instead specifies that a composite subtype MAY 119 specify whether or not a content-transfer-encoding can be used for 120 that subtype, with "cannot be used" as the default. 122 This document also updates Section 3.4 of [RFC5322]. It Extended 123 mailbox address syntax to permit UTF-8 character in Section 4.3. 125 Allowing use of a content-transfer-encoding on subtypes of messages 126 is not limited to transmissions that are authorized by the SMTP 127 extension specified in [I-D.ietf-eai-rfc5336bis]. message/global (see 128 Section 4.6) permits use of a content-transfer-encoding. 130 2. Background and History 132 Mailbox names often represent the names of human users. Many of 133 these users throughout the world have names that are not normally 134 expressed with just the ASCII repertoire of characters, and would 135 like to use more or less their real names in their mailbox names. 136 These users are also likely to use non-ASCII text in their display 137 names and subjects of email messages, both received and sent. This 138 protocol specifies UTF-8 as the encoding to represent email header 139 field bodies. 141 The traditional format of email messages [RFC5322] allows only ASCII 142 characters in the header fields of messages. This prevents users 143 from having email addresses that contain non-ASCII characters. It 144 further forces non-ASCII text in display names, comments, and in free 145 text (such as in the "Subject:" field) to be encoded (as required by 146 MIME format [RFC2047]). This specification describes a change to the 147 email message format that is related to the SMTP message transport 148 change described in the associated documents 149 [I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5336bis], and that 150 allows non-ASCII characters in most email header fields. These 151 changes affect SMTP clients, SMTP servers, mail user agents (MUAs), 152 list expanders, gateways to other media, and all other processes that 153 parse or handle email messages. 155 As specified in [I-D.ietf-eai-rfc5336bis], an SMTP protocol extension 156 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 157 header fields to systems that cannot handle such messages. 159 Use of this SMTP extension helps prevent the introduction of such 160 messages into message stores that might misinterpret, improperly 161 display, or mangle such messages. It should be noted that using an 162 ESMTP extension does not prevent transferring email messages with 163 UTF-8 header fields to other systems that use the email format for 164 messages and that may not be upgraded, such as unextended POP and 165 IMAP servers. Changes to these protocols to handle UTF-8 header 166 fields are addressed in [I-D.ietf-eai-rfc5721bis] and 167 [I-D.ietf-eai-5378bis]. 169 The objective for this protocol is to allow UTF-8 in email header 170 fields. 172 3. Terminology 174 A plain ASCII string is full compatible with [RFC5321] and [RFC5322]. 175 In this document, non-ASCII strings are UTF-8 strings if they are in 176 header which contain at least one . 178 Unless otherwise noted, all terms used here are defined in [RFC5321], 179 [RFC5322], [I-D.ietf-eai-frmwrk-4952bis], or 180 [I-D.ietf-eai-rfc5336bis]. 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 4. Changes on Message Header Fields 188 SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP 189 extension is advertised by the SMTP server or is permitted by other 190 transport mechanisms. 192 This protocol does NOT change the [RFC5322] rules for defining header 193 field names. The bodies of header fields are allowed to contain 194 UTF-8 characters, but the header field names themselves must contain 195 only ASCII characters. 197 To permit UTF-8 characters in field values, the header definition in 198 [RFC5322] is extended to support the new format. The following ABNF 199 is defined to substitute those definitions in [RFC5322]. 201 The syntax rules not covered in this section remain as defined in 202 [RFC5322]. 204 4.1. UTF-8 Syntax and Normalization 206 UTF-8 characters can be defined in terms of octets using the 207 following ABNF [RFC5234], taken from [RFC3629]: 209 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 211 UTF8-2 = 213 UTF8-3 = 215 UTF8-4 = 217 See [RFC5198] for a discussion of normalization; the use of 218 normalization form [NFC] is RECOMMENDED. Actually, if one is going 219 to do internationalization properly, one of the most often-cited 220 goals is to permit people to spell their names correctly. Since many 221 mailbox local parts reflect personal names, that principle applies as 222 well. And NFKC is not recommended because it may lose information 223 that is needed to correctly spell some names in unusual 224 circumstances. 226 4.2. Changes on MIME Headers 228 This specification updates Section 6.4 of [RFC2045]. [RFC2045] 229 prohibits applying a content-transfer-encoding to any subtypes of 230 "message/". This specification relaxes the rule -- it allows newly 231 defined MIME types to permit content-transfer-encoding, and it allows 232 content-transfer-encoding for message/global (see Section 4.6). 234 Background: Normally, transfer of message/global will be done in 235 8-bit-clean channels, and body parts will have "identity" encodings, 236 that is, no decoding is necessary. In the case where a message 237 containing a message/global is downgraded from 8-bit to 7-bit as 238 described in [RFC1652], an encoding may be applied to the message; if 239 the message travels multiple times between a 7-bit environment and an 240 environment implementing UTF8SMTP, multiple levels of encoding may 241 occur. This is expected to be rarely seen in practice, and the 242 potential complexity of other ways of dealing with the issue are 243 thought to be larger than the complexity of allowing nested encodings 244 where necessary. 246 4.3. Syntax Extensions to RFC 5322 248 The following rules are intended to extend the corresponding rules in 249 [RFC5322] in order to allow UTF-8 characters. 251 FWS = 253 CFWS = 255 ctext =/ UTF8-non-ascii 256 ; Extending ctext in RFC 5322, Section 3.2.2 257 comment = "(" *([FWS] uCcontent) [FWS] ")" 259 word = uAtom / uQuoted-String 261 This means that all the [RFC5322] constructs that build upon these 262 will permit UTF-8 characters, including comments and quoted strings. 263 We do not change the syntax of in order to allow UTF-8 264 characters in . This would also allow UTF-8 characters in 265 , which is not allowed due to the limitation described in 266 Section 4.5. Instead, is added to meet this requirement. 268 uText = %d1-9 / ; all UTF-8 characters except 269 %d11-12 / ; US-ASCII NUL, CR, and LF 270 %d14-127 / 271 UTF8-non-ascii 273 uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp 275 VCHAR = 277 WSP = 279 obs-qp = 281 uQcontent = uQtext / uQuoted-Pair 283 DQUOTE = 285 uCcontent = ctext / uQuoted-Pair / comment 287 uQtext = qtext / UTF8-non-ascii 289 uAtext = ALPHA / DIGIT / 290 "!" / "#" / ; Any character except 291 "$" / "%" / ; controls, SP, and specials. 292 "&" / "'" / ; Used for atoms. 293 "*" / "+" / 294 "-" / "/" / 295 "=" / "?" / 296 "^" / "_" / 297 "`" / "{" / 298 "|" / "}" / 299 "~" / 300 UTF8-non-ascii 302 uAtom = [CFWS] 1*uAtext [CFWS] 304 uDot-Atom = [CFWS] uDot-Atom-text [CFWS] 306 uDot-Atom-text = 1*uAtext *("." 1*uAtext) 308 qcontent =/ uQcontent 310 To allow the use of UTF-8 in a Content-Description header field 311 [RFC2045], the following syntax is used: 313 description = "Content-Description" ":" *uText 314 ; Replace description in RFC 2045, Section 8 316 The syntax is extended above to allow UTF-8 in all 317 header fields. 319 Note, however, this does not remove any constraint on the character 320 set of protocol elements; for instance, all the allowed values for 321 timezone in the "Date:" header fields are still expressed in ASCII. 322 And also, none of this revised syntax changes what is allowed in a 323 , which will still remain in pure ASCII. 325 4.4. Change on addr-spec Syntax 327 Internationalized email addresses are represented in UTF-8. Thus, 328 all header fields containing es are updated from [RFC5321] 329 Section 4.1.2 to permit UTF-8 addresses. 331 mailbox = name-addr / addr-spec / uAddr-Spec 332 ; Replace mailbox in RFC 5322, Section 3.4 334 angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS] 335 ; Extending angle-addr in RFC 5322, Section 3.4 337 uAddr-Spec = uLocal-Part "@" uDomain 339 uLocal-Part = uDot-Atom / uQuoted-String / obs-local-part 340 ; Replace Local-Part in RFC 5322, Section 3.4.1 342 uQuoted-String = [CFWS] DQUOTE *([FWS] uQcontent) [FWS] DQUOTE [CFWS] 344 obs-local-part = 345 uDomain = uDot-Atom / domain-literal / obs-domain 347 domain-literal = 349 Below are a few examples of possible representations. 351 "DISPLAY_NAME" 352 ; traditional mailbox format 354 "DISPLAY_NAME" 355 ; message will be rejected if UTF8SMTP extension is not supported 357 358 ; without DISPLAY_NAME and quoted string 359 ; message will be rejected if UTF8SMTP extension is not supported 361 4.5. Trace Field Syntax 363 The 'uFor' clause in "Received:" fields has been allowed the use of 364 internationalized addresses in "For" fields. It described in 365 [I-D.ietf-eai-rfc5336bis], Section 3.6.3. 367 The "Return-path" designates the address to which messages indicating 368 non-delivery or other mail system failures are to be sent. Thus, the 369 header is augmented to carry UTF-8 addresses (see the revised syntax 370 of in Section 4.4 of this document). This will not 371 break the rule of trace field integrity, because the header field is 372 added at the last MTA and described in [RFC5321]. 374 The on "Received:" field ( described in Section 375 3.6.7 of [RFC5322]) syntax is augmented to allow UTF-8 email address 376 in the "For" field. is augmented to include UTF-8 email 377 address. In order to allow UTF-8 email addresses in an , 378 is added to . 380 received-token =/ uAddr-Spec 382 4.6. message/global 384 Internationalized messages MUST only be transmitted as authorized by 385 [I-D.ietf-eai-rfc5336bis] or within a non-SMTP environment which 386 supports these messages. A message is a "message/global message", if 388 o it contains UTF-8 header values as specified in this document, or 390 o it contains UTF-8 values in the headers fields of body parts. 392 The type message/global is similar to message/rfc822, except that it 393 specifies that a message can contain UTF-8 characters in the headers 394 of the message or body parts. If this type is sent to a 7-bit-only 395 system, it has to be encoded in MIME [RFC2045]. (Note that a system 396 compliant with MIME that doesn't recognize message/global SHOULD 397 treat it as "application/octet-stream" as described in Section 5.2.4 398 of [RFC2046].) 400 Type name: message 402 Subtype name: global 404 Required parameters: none 405 Optional parameters: none 407 Encoding considerations: Any content-transfer-encoding is permitted. 408 The 8-bit or binary content-transfer-encodings are recommended 409 where permitted. 411 Security considerations: See Section 5. 413 Interoperability considerations: The media type provides 414 functionality similar to the message/rfc822 content type for email 415 messages with international email headers. When there is a need 416 to embed or return such content in another message, there is 417 generally an option to use this media type and leave the content 418 unchanged or down-convert the content to message/rfc822. Both of 419 these choices will interoperate with the installed base, but with 420 different properties. Systems unaware of internationalized 421 headers will typically treat a message/global body part as an 422 unknown attachment, while they will understand the structure of a 423 message/rfc822. However, systems that understand message/global 424 will provide functionality superior to the result of a down- 425 conversion to message/rfc822. The most interoperable choice 426 depends on the deployed software. 428 Published specification: RFC XXXX 430 Applications that use this media type: SMTP servers and email 431 clients that support multipart/report generation or parsing. 432 Email clients which forward messages with international headers as 433 attachments. 435 Additional information: 437 Magic number(s): none 439 File extension(s): The extension ".u8msg" is suggested. 441 Macintosh file type code(s): A uniform type identifier (UTI) of 442 "public.utf8-email-message" is suggested. This conforms to 443 "public.message" and "public.composite-content", but does not 444 necessarily conform to "public.utf8-plain-text". 446 Person & email address to contact for further information: See the 447 Author's Address section of this document. 449 Intended usage: COMMON 450 Restrictions on usage: This is a structured media type which embeds 451 other MIME media types. The 8-bit or binary content-transfer- 452 encoding SHOULD be used unless this media type is sent over a 453 7-bit-only transport. 455 Author: See the Author's Address section of this document. 457 Change controller: IETF Standards Process 459 5. Security Considerations 461 If a user has a non-ASCII mailbox address and an ASCII mailbox 462 address, a digital certificate that identifies that user may have 463 both addresses in the identity. Having multiple email addresses as 464 identities in a single certificate is already supported in PKIX 465 (Public Key Infrastructure for X.509 Certificates) [RFC5280] and 466 OpenPGP [RFC3156]. 468 Because UTF-8 often requires several octets to encode a single 469 character, internationalized local parts and header value may cause 470 mail addresses to become longer. As specified in [RFC5322], each 471 line of characters MUST be no more 998 octets, excluding the CRLF. 472 On the other hand, MDA (Mail Delivery Agent) processes that parse, 473 store, or handle email addresses or local parts must take extra care 474 not to overflow buffers, truncate addresses, or exceed storage 475 allotments. Also, they must take care, when comparing, to use the 476 entire lengths of the addresses. 478 In this specification, a user could provide an ASCII alternative 479 address for a non-ASCII address. However, it is possible these two 480 addresses go to different mailboxes, or even different people. This 481 configuration may be based on a user's personal choice or on 482 administration policy. We recognize that if ASCII and non-ASCII 483 email is delivered to two different destinations, based on MTA 484 capability, this may violate the principle of least astonishment, but 485 this is not a "protocol problem". 487 The security impact of UTF-8 headers on email signature systems such 488 as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is 489 discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14. 491 6. IANA Considerations 493 IANA is requested to update the registration of the message/global 494 MIME type using the registration form contained in Section 4.6. 496 7. Acknowledgements 498 This document incorporates many ideas first described in Internet- 499 Draft form by Paul Hoffman, although many details have changed from 500 that earlier work. 502 The author especially thanks Jeff Yeh for his efforts and 503 contributions on editing previous versions. 505 Most of the content of this document is provided by John C Klensin. 506 Also, some significant comments and suggestions were received from 507 Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris 508 Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team 509 (Joint Engineering Team) and were incorporated into the document. 510 The editor sincerely thanks them for their contributions. 512 8. Edit history 514 [[RFC Editor: please remove this section before publishing.]] 516 8.1. draft-ietf-eai-rfc5335bis-00 518 1. Applied Errata suggested by Alfred Hoenes. 520 2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322]. 522 3. Abrogate in ABNF of . 524 4. Revoke [RFC5504] from this document. 526 5. Upgrade some references from I-Ds to RFC. 528 8.2. draft-ietf-eai-rfc5335bis-01 530 1. Author name revised. 532 8.3. draft-ietf-eai-rfc5335bis-02 534 1. ABNF revised. 536 8.4. draft-ietf-eai-rfc5335bis-03 538 1. Fix typos 540 2. ABNF revised 542 3. Improve sentence 544 8.5. draft-ietf-eai-rfc5335bis-04 546 1. improve sentences and ABNF revised based on AD and Co-chairs 548 8.6. draft-ietf-eai-rfc5335bis-05 550 1. ABNF revised in Section 4.4 based on AD comments 552 8.7. draft-ietf-eai-rfc5335bis-06 554 1. ABNF revised 556 2. improve Section 6 558 9. References 560 9.1. Normative References 562 [I-D.ietf-eai-5378bis] Resnick, P., Newman, C., and S. Shen, 563 "IMAP Support for UTF-8", 564 draft-ietf-eai-5378bis-00 (work in 565 progress), November 2010. 567 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 568 Framework for Internationalized 569 Email", 570 draft-ietf-eai-frmwrk-4952bis-10 (work 571 in progress), September 2010. 573 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 574 for Internationalized Email Address", 575 draft-ietf-eai-rfc5336bis-07 (work in 576 progress), December 2010. 578 [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and 579 K. Fujiwara, "POP3 Support for UTF-8", 580 draft-ietf-eai-rfc5721bis-00 (work in 581 progress), September 2010. 583 [NFC] Davis, M. and K. Whistler, "Unicode 584 Standard Annex #15: Unicode 585 Normalization Forms", September 2010, 586 . 589 [RFC2119] Bradner, S., "Key words for use in 590 RFCs to Indicate Requirement Levels", 591 BCP 14, RFC 2119, March 1997. 593 [RFC3629] Yergeau, F., "UTF-8, a transformation 594 format of ISO 10646", STD 63, 595 RFC 3629, November 2003. 597 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 598 Format for Network Interchange", 599 RFC 5198, March 2008. 601 [RFC5234] Crocker, D. and P. Overell, "Augmented 602 BNF for Syntax Specifications: ABNF", 603 STD 68, RFC 5234, January 2008. 605 [RFC5321] Klensin, J., "Simple Mail Transfer 606 Protocol", RFC 5321, October 2008. 608 [RFC5322] Resnick, P., Ed., "Internet Message 609 Format", RFC 5322, October 2008. 611 9.2. Informative References 613 [RFC1652] Klensin, J., Freed, N., Rose, M., 614 Stefferud, E., and D. Crocker, "SMTP 615 Service Extension for 8bit- 616 MIMEtransport", RFC 1652, July 1994. 618 [RFC2045] Freed, N. and N. Borenstein, 619 "Multipurpose Internet Mail Extensions 620 (MIME) Part One: Format of Internet 621 Message Bodies", RFC 2045, 622 November 1996. 624 [RFC2046] Freed, N. and N. Borenstein, 625 "Multipurpose Internet Mail Extensions 626 (MIME) Part Two: Media Types", 627 RFC 2046, November 1996. 629 [RFC2047] Moore, K., "MIME (Multipurpose 630 Internet Mail Extensions) Part Three: 631 Message Header Extensions for Non- 632 ASCII Text", RFC 2047, November 1996. 634 [RFC3156] Elkins, M., Del Torto, D., Levien, R., 635 and T. Roessler, "MIME Security with 636 OpenPGP", RFC 3156, August 2001. 638 [RFC5280] Cooper, D., Santesson, S., Farrell, 639 S., Boeyen, S., Housley, R., and W. 640 Polk, "Internet X.509 Public Key 641 Infrastructure Certificate and 642 Certificate Revocation List (CRL) 643 Profile", RFC 5280, May 2008. 645 Authors' Addresses 647 Abel Yang 648 TWNIC 649 4F-2, No. 9, Sec 2, Roosevelt Rd. 650 Taipei, 100 651 Taiwan 653 Phone: +886 2 23411313 ext 505 654 EMail: abelyang@twnic.net.tw 656 Shawn Steele 657 Microsoft 659 EMail: Shawn.Steele@microsoft.com