idnits 2.17.1 draft-ietf-eai-rfc5335bis-05.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 04, 2010) is 4864 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 517, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) == Missing Reference: 'RFC2822' is mentioned on line 517, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'RFC5504' is mentioned on line 521, 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-05 == Outdated reference: A later version (-08) exists of draft-ietf-eai-rfc5721bis-00 -- Obsolete informational reference (is this intentional?): RFC 1652 (Obsoleted by RFC 6152) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 04, 2010 7 (if approved) 8 Intended status: Standards Track 9 Expires: June 7, 2011 11 Internationalized Email Headers 12 draft-ietf-eai-rfc5335bis-05 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 7, 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 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 1.1. Role of This Specification 92 Full internationalization of electronic mail requires several 93 capabilities: 95 o The capability to transmit non-ASCII content, provided for as part 96 of the basic MIME specification [RFC2045], [RFC2046]. 98 o The capability to use international characters in envelope 99 addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and 100 specified in [I-D.ietf-eai-rfc5336bis]. 102 o The capability to express those addresses, and information related 103 to them and based on them, in mail header fields, defined in this 104 document. 106 This document specifies a variant of Internet mail that permits the 107 use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the 108 base form for Internet email header fields. This form is permitted 109 in transmission, if authorized by the SMTP extension specified in 110 [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of 111 processing it. 113 1.2. Relation to Other Standards 115 This document updates Section 6.4 of [RFC2045]. It removes the 116 blanket ban on applying a content-transfer-encoding to all subtypes 117 of message/ and instead specifies that a composite subtype MAY 118 specify whether or not a content-transfer-encoding can be used for 119 that subtype, with "cannot be used" as the default. 121 This document also updates Section 3.4 of [RFC5322]. It Extended 122 mailbox address syntax to permit UTF-8 character in Section 4.3. 124 Allowing use of a content-transfer-encoding on subtypes of messages 125 is not limited to transmissions that are authorized by the SMTP 126 extension specified in [I-D.ietf-eai-rfc5336bis]. message/global (see 127 Section 4.6) permits use of a content-transfer-encoding. 129 2. Background and History 131 Mailbox names often represent the names of human users. Many of 132 these users throughout the world have names that are not normally 133 expressed with just the ASCII repertoire of characters, and would 134 like to use more or less their real names in their mailbox names. 135 These users are also likely to use non-ASCII text in their display 136 names and subjects of email messages, both received and sent. This 137 protocol specifies UTF-8 as the encoding to represent email header 138 field bodies. 140 The traditional format of email messages [RFC5322] allows only ASCII 141 characters in the header fields of messages. This prevents users 142 from having email addresses that contain non-ASCII characters. It 143 further forces non-ASCII text in display names, comments, and in free 144 text (such as in the "Subject:" field) to be encoded (as required by 145 MIME format [RFC2047]). This specification describes a change to the 146 email message format that is related to the SMTP message transport 147 change described in the associated documents 148 [I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5336bis], and that 149 allows non-ASCII characters in most email header fields. These 150 changes affect SMTP clients, SMTP servers, mail user agents (MUAs), 151 list expanders, gateways to other media, and all other processes that 152 parse or handle email messages. 154 As specified in [I-D.ietf-eai-rfc5336bis], an SMTP protocol extension 155 "UTF8SMTPbis" is used to prevent the transmission of messages with 156 UTF-8 header fields to systems that cannot handle such messages. 158 Use of this SMTP extension helps prevent the introduction of such 159 messages into message stores that might misinterpret, improperly 160 display, or mangle such messages. It should be noted that using an 161 ESMTP extension does not prevent transferring email messages with 162 UTF-8 header fields to other systems that use the email format for 163 messages and that may not be upgraded, such as unextended POP and 164 IMAP servers. Changes to these protocols to handle UTF-8 header 165 fields are addressed in [I-D.ietf-eai-rfc5721bis] and 166 [I-D.ietf-eai-5378bis]. 168 The objective for this protocol is to allow UTF-8 in email header 169 fields. 171 3. Terminology 173 A plain ASCII string is full compatible with [RFC5321] and [RFC5322]. 174 In this document, non-ASCII strings are UTF-8 strings if they are in 175 header which contain at least one . 177 Unless otherwise noted, all terms used here are defined in [RFC5321], 178 [RFC5322], [I-D.ietf-eai-frmwrk-4952bis], or 179 [I-D.ietf-eai-rfc5336bis]. 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 4. Changes on Message Header Fields 187 SMTP clients can send header fields in UTF-8 format, if the 188 UTF8SMTPbis extension is advertised by the SMTP server or is 189 permitted by other transport mechanisms. 191 This protocol does NOT change the [RFC5322] rules for defining header 192 field names. The bodies of header fields are allowed to contain 193 UTF-8 characters, but the header field names themselves must contain 194 only ASCII characters. 196 To permit UTF-8 characters in field values, the header definition in 197 [RFC5322] is extended to support the new format. The following ABNF 198 is defined to substitute those definitions in [RFC5322]. 200 The syntax rules not covered in this section remain as defined in 201 [RFC5322]. 203 4.1. UTF-8 Syntax and Normalization 205 UTF-8 characters can be defined in terms of octets using the 206 following ABNF [RFC5234], taken from [RFC3629]: 208 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 210 UTF8-2 = 212 UTF8-3 = 214 UTF8-4 = 216 See [RFC5198] for a discussion of normalization; the use of 217 normalization form [NFC] is RECOMMENDED. Actually, if one is going 218 to do internationalization properly, one of the most often-cited 219 goals is to permit people to spell their names correctly. Since many 220 mailbox local parts reflect personal names, that principle applies as 221 well. And NFKC is not recommended because it may lose information 222 that is needed to correctly spell some names in unusual 223 circumstances. 225 4.2. Changes on MIME Headers 227 This specification updates Section 6.4 of [RFC2045]. [RFC2045] 228 prohibits applying a content-transfer-encoding to any subtypes of 229 "message/". This specification relaxes the rule -- it allows newly 230 defined MIME types to permit content-transfer-encoding, and it allows 231 content-transfer-encoding for message/global (see Section 4.6). 233 Background: Normally, transfer of message/global will be done in 234 8-bit-clean channels, and body parts will have "identity" encodings, 235 that is, no decoding is necessary. In the case where a message 236 containing a message/global is downgraded from 8-bit to 7-bit as 237 described in [RFC1652], an encoding may be applied to the message; if 238 the message travels multiple times between a 7-bit environment and an 239 environment implementing UTF8SMTPbis, multiple levels of encoding may 240 occur. This is expected to be rarely seen in practice, and the 241 potential complexity of other ways of dealing with the issue are 242 thought to be larger than the complexity of allowing nested encodings 243 where necessary. 245 4.3. Syntax Extensions to RFC 5322 247 The following rules are intended to extend the corresponding rules in 248 [RFC5322] in order to allow UTF-8 characters. 250 FWS = 252 CFWS = 254 ctext =/ UTF8-non-ascii 256 comment = "(" *([FWS] uCcontent) [FWS] ")" 258 word = uAtom / uQuoted-String 260 This means that all the [RFC5322] constructs that build upon these 261 will permit UTF-8 characters, including comments and quoted strings. 262 We do not change the syntax of in order to allow UTF-8 263 characters in . This would also allow UTF-8 characters in 264 , which is not allowed due to the limitation described in 265 Section 4.5. Instead, is added to meet this requirement. 267 uText = %d1-9 / ; all UTF-8 characters except 268 %d11-12 / ; US-ASCII NUL, CR, and LF 269 %d14-127 / 270 UTF8-non-ascii 272 uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp 274 VCHAR = 276 WSP = 278 uQcontent = uQtext / uQuoted-Pair 280 uQuoted-Pair = ("\" uText) / obs-qp 282 DQUOTE = 284 uCcontent = ctext / uQuoted-Pair / comment 286 uQtext = qtext / UTF8-non-ascii 288 uAtext = ALPHA / DIGIT / 289 "!" / "#" / ; Any character except 290 "$" / "%" / ; controls, SP, and specials. 291 "&" / "'" / ; Used for atoms. 292 "*" / "+" / 293 "-" / "/" / 294 "=" / "?" / 295 "^" / "_" / 296 "`" / "{" / 297 "|" / "}" / 298 "~" / 299 UTF8-non-ascii 301 uAtom = [CFWS] 1*uAtext [CFWS] 303 uDot-Atom = [CFWS] uDot-Atom-text [CFWS] 305 uDot-Atom-text = 1*uAtext *("." 1*uAtext) 307 qcontent =/ uQcontent 309 To allow the use of UTF-8 in a Content-Description header field 310 [RFC2045], the following syntax is used: 312 description = "Content-Description" ":" *uText 313 ; Replace description in Section 8 of [RFC2045] 315 The syntax is extended above to allow UTF-8 in all 316 header fields. 318 Note, however, this does not remove any constraint on the character 319 set of protocol elements; for instance, all the allowed values for 320 timezone in the "Date:" header fields are still expressed in ASCII. 321 And also, none of this revised syntax changes what is allowed in a 322 , which will still remain in pure ASCII. 324 4.4. Change on addr-spec Syntax 326 Internationalized email addresses are represented in UTF-8. Thus, 327 all header fields containing es are updated from [RFC5321] 328 Section 4.1.2 to permit UTF-8 addresses. 330 mailbox = name-addr / addr-spec / uAddr-Spec 331 ; Replace mailbox in Section 3.4 of RFC 5322 333 angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS] 334 ; Replace angle-addr in Section 3.4 of RFC 5322 336 uAddr-Spec = uLocal-Part "@" uDomain 338 uLocal-Part = uDot-Atom / uQuoted-String / obs-local-part 339 ; Replace Local-Part in Section 3.4.1 of RFC 5322 341 uDomain = uDot-Atom / domain-literal / obs-domain 343 domain-literal = 345 Below are a few examples of possible representations. 347 "DISPLAY_NAME" 348 ; traditional mailbox format 350 "DISPLAY_NAME" 351 ; message will be rejected if UTF8SMTPbis extension is not supported 353 354 ; without DISPLAY_NAME and quoted string 355 ; message will be rejected if UTF8SMTPbis extension is not supported 357 4.5. Trace Field Syntax 359 The 'uFor' clause in "Received:" fields has been allowed the use of 360 internationalized addresses in "For" fields. It described in 361 [I-D.ietf-eai-rfc5336bis], Section 3.6.3. 363 The "Return-path" designates the address to which messages indicating 364 non-delivery or other mail system failures are to be sent. Thus, the 365 header is augmented to carry UTF-8 addresses (see the revised syntax 366 of in Section 4.4 of this document). This will not 367 break the rule of trace field integrity, because the header field is 368 added at the last MTA and described in [RFC5321]. 370 The on "Received:" field ( described in Section 371 3.6.7 of [RFC5322]) syntax is augmented to allow UTF-8 email address 372 in the "For" field. is augmented to include UTF-8 email 373 address. In order to allow UTF-8 email addresses in an , 374 is added to . 376 received-token =/ uAddr-Spec 378 4.6. message/global 380 Internationalized messages MUST only be transmitted as authorized by 381 [I-D.ietf-eai-rfc5336bis] or within a non-SMTP environment which 382 supports these messages. A message is a "message/global message", if 384 o it contains UTF-8 header values as specified in this document, or 386 o it contains UTF-8 values in the headers fields of body parts. 388 The type message/global is similar to message/rfc822, except that it 389 specifies that a message can contain UTF-8 characters in the headers 390 of the message or body parts. If this type is sent to a 7-bit-only 391 system, it has to be encoded in MIME [RFC2045]. (Note that a system 392 compliant with MIME that doesn't recognize message/global SHOULD 393 treat it as "application/octet-stream" as described in Section 5.2.4 394 of [RFC2046].) 396 Type name: message 398 Subtype name: global 400 Required parameters: none 401 Optional parameters: none 403 Encoding considerations: Any content-transfer-encoding is permitted. 404 The 8-bit or binary content-transfer-encodings are recommended 405 where permitted. 407 Security considerations: See Section 5. 409 Interoperability considerations: The media type provides 410 functionality similar to the message/rfc822 content type for email 411 messages with international email headers. When there is a need 412 to embed or return such content in another message, there is 413 generally an option to use this media type and leave the content 414 unchanged or down-convert the content to message/rfc822. Both of 415 these choices will interoperate with the installed base, but with 416 different properties. Systems unaware of internationalized 417 headers will typically treat a message/global body part as an 418 unknown attachment, while they will understand the structure of a 419 message/rfc822. However, systems that understand message/global 420 will provide functionality superior to the result of a down- 421 conversion to message/rfc822. The most interoperable choice 422 depends on the deployed software. 424 Published specification: RFC XXXX 426 Applications that use this media type: SMTP servers and email 427 clients that support multipart/report generation or parsing. 428 Email clients which forward messages with international headers as 429 attachments. 431 Additional information: 433 Magic number(s): none 435 File extension(s): The extension ".u8msg" is suggested. 437 Macintosh file type code(s): A uniform type identifier (UTI) of 438 "public.utf8-email-message" is suggested. This conforms to 439 "public.message" and "public.composite-content", but does not 440 necessarily conform to "public.utf8-plain-text". 442 Person & email address to contact for further information: See the 443 Author's Address section of this document. 445 Intended usage: COMMON 446 Restrictions on usage: This is a structured media type which embeds 447 other MIME media types. The 8-bit or binary content-transfer- 448 encoding SHOULD be used unless this media type is sent over a 449 7-bit-only transport. 451 Author: See the Author's Address section of this document. 453 Change controller: IETF Standards Process 455 5. Security Considerations 457 If a user has a non-ASCII mailbox address and an ASCII mailbox 458 address, a digital certificate that identifies that user may have 459 both addresses in the identity. Having multiple email addresses as 460 identities in a single certificate is already supported in PKIX 461 (Public Key Infrastructure for X.509 Certificates) [RFC5280] and 462 OpenPGP [RFC3156]. 464 Because UTF-8 often requires several octets to encode a single 465 character, internationalized local parts and header value may cause 466 mail addresses to become longer. As specified in [RFC5322], each 467 line of characters MUST be no more 998 octets, excluding the CRLF. 468 On the other hand, MDA (Mail Delivery Agent) processes that parse, 469 store, or handle email addresses or local parts must take extra care 470 not to overflow buffers, truncate addresses, or exceed storage 471 allotments. Also, they must take care, when comparing, to use the 472 entire lengths of the addresses. 474 In this specification, a user could provide an ASCII alternative 475 address for a non-ASCII address. However, it is possible these two 476 addresses go to different mailboxes, or even different people. This 477 configuration may be based on a user's personal choice or on 478 administration policy. We recognize that if ASCII and non-ASCII 479 email is delivered to two different destinations, based on MTA 480 capability, this may violate the principle of least astonishment, but 481 this is not a "protocol problem". 483 The security impact of UTF-8 headers on email signature systems such 484 as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is 485 discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14. 487 6. IANA Considerations 489 IANA has registered the message/global MIME type using the 490 registration form contained in Section 4.4. 492 7. Acknowledgements 494 This document incorporates many ideas first described in Internet- 495 Draft form by Paul Hoffman, although many details have changed from 496 that earlier work. 498 The author especially thanks Jeff Yeh for his efforts and 499 contributions on editing previous versions. 501 Most of the content of this document is provided by John C Klensin. 502 Also, some significant comments and suggestions were received from 503 Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris 504 Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team 505 (Joint Engineering Team) and were incorporated into the document. 506 The editor sincerely thanks them for their contributions. 508 8. Edit history 510 This section is used for tracking the update of this document. Will 511 be removed after finalize. 513 8.1. draft-ietf-eai-rfc5335bis-00 515 1. Applied Errata suggested by Alfred Hoenes. 517 2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322]. 519 3. Abrogate in ABNF of . 521 4. Revoke [RFC5504] from this document. 523 5. Upgrade some references from I-Ds to RFC. 525 8.2. draft-ietf-eai-rfc5335bis-01 527 1. Author name revised. 529 8.3. draft-ietf-eai-rfc5335bis-02 531 1. ABNF revised. 533 8.4. draft-ietf-eai-rfc5335bis-03 535 1. Fix typos 537 2. ABNF revised 538 3. Improve sentence 540 8.5. draft-ietf-eai-rfc5335bis-04 542 1. improve sentences and ABNF revised based on AD and Co-chairs 544 8.6. draft-ietf-eai-rfc5335bis-05 546 1. ABNF revised in Section 4.4 based on AD comments 548 9. References 550 9.1. Normative References 552 [I-D.ietf-eai-5378bis] Resnick, P., Newman, C., and S. Shen, 553 "IMAP Support for UTF-8", 554 draft-ietf-eai-5378bis-00 (work in 555 progress), November 2010. 557 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 558 Framework for Internationalized 559 Email", 560 draft-ietf-eai-frmwrk-4952bis-10 (work 561 in progress), September 2010. 563 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 564 for Internationalized Email Address", 565 draft-ietf-eai-rfc5336bis-05 (work in 566 progress), December 2010. 568 [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and 569 K. Fujiwara, "POP3 Support for UTF-8", 570 draft-ietf-eai-rfc5721bis-00 (work in 571 progress), September 2010. 573 [RFC2119] Bradner, S., "Key words for use in 574 RFCs to Indicate Requirement Levels", 575 BCP 14, RFC 2119, March 1997. 577 [RFC3629] Yergeau, F., "UTF-8, a transformation 578 format of ISO 10646", STD 63, 579 RFC 3629, November 2003. 581 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 582 Format for Network Interchange", 583 RFC 5198, March 2008. 585 [RFC5234] Crocker, D. and P. Overell, "Augmented 586 BNF for Syntax Specifications: ABNF", 587 STD 68, RFC 5234, January 2008. 589 [RFC5321] Klensin, J., "Simple Mail Transfer 590 Protocol", RFC 5321, October 2008. 592 [RFC5322] Resnick, P., Ed., "Internet Message 593 Format", RFC 5322, October 2008. 595 9.2. Informative References 597 [NFC] Davis, M. and K. Whistler, "Unicode 598 Standard Annex #15: Unicode 599 Normalization Forms", September 2010, 600 . 603 [RFC1652] Klensin, J., Freed, N., Rose, M., 604 Stefferud, E., and D. Crocker, "SMTP 605 Service Extension for 8bit- 606 MIMEtransport", RFC 1652, July 1994. 608 [RFC2045] Freed, N. and N. Borenstein, 609 "Multipurpose Internet Mail Extensions 610 (MIME) Part One: Format of Internet 611 Message Bodies", RFC 2045, 612 November 1996. 614 [RFC2046] Freed, N. and N. Borenstein, 615 "Multipurpose Internet Mail Extensions 616 (MIME) Part Two: Media Types", 617 RFC 2046, November 1996. 619 [RFC2047] Moore, K., "MIME (Multipurpose 620 Internet Mail Extensions) Part Three: 621 Message Header Extensions for Non- 622 ASCII Text", RFC 2047, November 1996. 624 [RFC3156] Elkins, M., Del Torto, D., Levien, R., 625 and T. Roessler, "MIME Security with 626 OpenPGP", RFC 3156, August 2001. 628 [RFC5280] Cooper, D., Santesson, S., Farrell, 629 S., Boeyen, S., Housley, R., and W. 630 Polk, "Internet X.509 Public Key 631 Infrastructure Certificate and 632 Certificate Revocation List (CRL) 633 Profile", RFC 5280, May 2008. 635 Authors' Addresses 637 Abel Yang 638 TWNIC 639 4F-2, No. 9, Sec 2, Roosevelt Rd. 640 Taipei, 100 641 Taiwan 643 Phone: +886 2 23411313 ext 505 644 EMail: abelyang@twnic.net.tw 646 Shawn Steele 647 Microsoft 649 EMail: Shawn.Steele@microsoft.com