idnits 2.17.1 draft-ietf-eai-rfc5335bis-02.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 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 (August 19, 2010) is 4992 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: 'CFWS' is mentioned on line 335, but not defined == Missing Reference: 'RFC2821' is mentioned on line 519, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) == Missing Reference: 'RFC2822' is mentioned on line 519, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Unused Reference: 'RFC5721' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC5738' is defined on line 604, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-eai-frmwrk-4952bis-02 -- Unexpected draft version: The latest known version of draft-yao-eai-rfc5336bis is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'I-D.yao-eai-rfc5336bis' ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) -- Obsolete informational reference (is this intentional?): RFC 5721 (Obsoleted by RFC 6856) -- Obsolete informational reference (is this intentional?): RFC 5738 (Obsoleted by RFC 6855) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization A. Yang 3 (EAI) TWNIC 4 Internet-Draft S. Steele 5 Obsoletes: 5335 (if approved) Microsoft 6 Updates: 2045, 5322 August 19, 2010 7 (if approved) 8 Intended status: Standards Track 9 Expires: February 20, 2011 11 Internationalized Email Headers 12 draft-ietf-eai-rfc5335bis-02 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 an 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 February 20, 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 . . . . . . . . . . . . . . . . . 6 70 4.3. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 6 71 4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8 72 4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 8 73 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 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 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 1.1. Role of This Specification 89 Full internationalization of electronic mail requires several 90 capabilities: 92 o The capability to transmit non-ASCII content, provided for as part 93 of the basic MIME specification [RFC2045], [RFC2046]. 95 o The capability to use international characters in envelope 96 addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and 97 specified in [I-D.yao-eai-rfc5336bis]. 99 o The capability to express those addresses, and information related 100 to them and based on them, in mail header fields, defined in this 101 document. 103 This document specifies an variant of Internet mail that permits the 104 use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the 105 base form for Internet email header fields. This form is permitted 106 in transmission, if authorized by the SMTP extension specified in 107 [I-D.yao-eai-rfc5336bis] or by other transport mechanisms capable of 108 processing it. 110 1.2. Relation to Other Standards 112 This document updates Section 6.4 of [RFC2045]. It removes the 113 blanket ban on applying a content-transfer-encoding to all subtypes 114 of message/, and instead specifies that a composite subtype MAY 115 specify whether or not a content-transfer-encoding can be used for 116 that subtype, with "cannot be used" as the default. 118 This document also updates [RFC5322] and MIME ([RFC2045]), and people 119 who participate in the experiment have to swich to this document. 121 Allowing use of a content-transfer-encoding on subtypes of messages 122 is not limited to transmissions that are authorized by the SMTP 123 extension specified in [I-D.yao-eai-rfc5336bis]. Message/global (see 124 Section 4.6) permits use of a content-transfer-encoding. 126 2. Background and History 128 Mailbox names often represent the names of human users. Many of 129 these users throughout the world have names that are not normally 130 expressed with just the ASCII repertoire of characters, and would 131 like to use more or less their real names in their mailbox names. 132 These users are also likely to use non-ASCII text in their common 133 names and subjects of email messages, both received and sent. This 134 protocol specifies UTF-8 as the encoding to represent email header 135 field bodies. 137 The traditional format of email messages [RFC5322] allows only ASCII 138 characters in the header fields of messages. This prevents users 139 from having email addresses that contain non-ASCII characters. It 140 further forces non-ASCII text in common names, comments, and in free 141 text (such as in the Subject: field) to be encoded (as required by 142 MIME format [RFC2047]). This specification describes a change to the 143 email message format that is related to the SMTP message transport 144 change described in the associated document 145 [I-D.ietf-eai-frmwrk-4952bis] and [I-D.yao-eai-rfc5336bis], and that 146 allows non-ASCII characters in most email header fields. These 147 changes affect SMTP clients, SMTP servers, mail user agents (MUAs), 148 list expanders, gateways to other media, and all other processes that 149 parse or handle email messages. 151 As specified in [I-D.yao-eai-rfc5336bis], an SMTP protocol extension 152 "UTF8SMTPbis" is used to prevent the transmission of messages with 153 UTF-8 header fields to systems that cannot handle such messages. 154 [[Note in Draft: Keyword related to UTF8SMTP will be decided by WG 155 before publication.]] 157 Use of this SMTP extension helps prevent the introduction of such 158 messages into message stores that might misinterpret, improperly 159 display, or mangle such messages. It should be noted that using an 160 ESMTP extension does not prevent transferring email messages with 161 UTF-8 header fields to other systems that use the email format for 162 messages and that may not be upgraded, such as unextended POP and 163 IMAP servers. Changes to these protocols to handle UTF-8 header 164 fields are addressed in [RFC5721]-bis and [RFC5738]-bis. 166 The objective for this protocol is to allow UTF-8 in email header 167 fields. 169 3. Terminology 171 A plain ASCII string is also a valid UTF-8 string; see [RFC3629]. In 172 this document, ordinary ASCII characters are UTF-8 characters if they 173 are in headers which contain s. 175 Unless otherwise noted, all terms used here are defined in [RFC5321], 176 [RFC5322], [I-D.ietf-eai-frmwrk-4952bis],or [I-D.yao-eai-rfc5336bis]. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 4. Changes on Message Header Fields 184 SMTP clients can send header fields in UTF-8 format, if the 185 UTF8SMTPbis extension is advertised by the SMTP server or is 186 permitted by other transport mechanisms. 188 This protocol does NOT change the [RFC5322] rules for defining header 189 field names. The bodies of header fields are allowed to contain 190 UTF-8 characters, but the header field names themselves must contain 191 only ASCII characters. 193 To permit UTF-8 characters in field values, the header definition in 194 [RFC5322] must be extended to support the new format. The following 195 ABNF is defined to substitute those definitions in [RFC5322]. 197 The syntax rules not covered in this section remain as defined in 198 [RFC5322]. 200 4.1. UTF-8 Syntax and Normalization 202 UTF-8 characters can be defined in terms of octets using the 203 following ABNF [RFC5234], taken from [RFC3629]: 205 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 207 UTF8-2 = %xC2-DF UTF8-tail 209 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 210 %xE1-EC 2(UTF8-tail) / 211 %xED %x80-9F UTF8-tail / 212 %xEE-EF 2(UTF8-tail) 214 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 215 %xF1-F3 3( UTF8-tail ) / 216 %xF4 %x80-8F 2( UTF8-tail ) 218 UTF8-tail = %x80-BF 220 These are normatively defined in [RFC3629], but kept in this document 221 for reasons of convenience. 223 See [RFC5198] for a discussion of normalization; the use of 224 normalization form NFC is RECOMMENDED. Actually, if one is going to 225 do internationalization properly, one of the most often-cited goals 226 is to permit people to spell their names correctly. Since many 227 mailbox local parts reflect personal names, that principle applies as 228 well. And NFKC is not recommended because it may lose information 229 that is needed to correctly spell some names except in unusual 230 circumstances. 232 4.2. Changes on MIME Headers 234 This specification updates Section 6.4 of [RFC2045]. [RFC2045] 235 prohibits applying a content-transfer-encoding to all subtypes of 236 message/. This specification relaxes the rule -- it allows newly 237 defined MIME types to permit content-transfer-encoding, and it allows 238 content-transfer-encoding for message/global (see Section 4.6). 240 Background: Normally, transfer of message/global will be done in 241 8-bit-clean channels, and body parts will have "identity" encodings, 242 that is, no decoding is necessary. In the case where a message 243 containing a message/global is downgraded from 8-bit to 7-bit as 244 described in [RFC1652], an encoding may be applied to the message; if 245 the message travels multiple times between a 7-bit environment and an 246 environment implementing UTF8SMTPbis, multiple levels of encoding may 247 occur. This is expected to be rarely seen in practice, and the 248 potential complexity of other ways of dealing with the issue are 249 thought to be larger than the complexity of allowing nested encodings 250 where necessary. 252 4.3. Syntax Extensions to RFC 5322 254 The following rules are intended to extend the corresponding rules in 255 [RFC5322] in order to allow UTF-8 characters. 257 FWS = 259 CFWS = 261 ctext =/ UTF8-xtra-char 263 utext =/ UTF8-xtra-char 265 comment = "(" *([FWS] uCcontent) [FWS] ")" 267 word = uAtom / uQuoted-String 269 This means that all the [RFC5322] constructs that build upon these 270 will permit UTF-8 characters, including comments and quoted strings. 271 We do not change the syntax of in order to allow UTF-8 272 characters in . This would also allow UTF-8 characters in 273 , which is not allowed due to the limitation described in 274 Section 4.5. Instead, is added to meet this requirement. 276 uText = %d1-9 / ; all UTF-8 characters except 277 %d11-12 / ; US-ASCII NUL, CR, and LF 278 %d14-127 / 279 UTF8-xtra-char 281 uQuoted-Pair = ("\" uText) / obs-qp 283 uQcontent = uQtext / uQuoted-Pair 285 uQuoted-String = [CFWS] 286 DQUOTE *([FWS] uQcontent) [FWS] DQUOTE 287 [CFWS] 289 uCcontent = ctext / uQuoted-Pair / comment 290 uQtext = qtext / UTF8-xtra-char 292 uAtext = ALPHA / DIGIT / 293 "!" / "#" / ; Any character except 294 "$" / "%" / ; controls, SP, and specials. 295 "&" / "'" / ; Used for atoms. 296 "*" / "+" / 297 "-" / "/" / 298 "=" / "?" / 299 "^" / "_" / 300 "`" / "{" / 301 "|" / "}" / 302 "~" / 303 UTF8-xtra-char 305 uAtom = [CFWS] 1*uAtext [CFWS] 307 uDot-Atom = [CFWS] uDot-Atom-text [CFWS] 309 uDot-Atom-text = 1*uAtext *("." 1*uAtext) 311 qcontent = uQcontent 313 To allow the use of UTF-8 in a Content-Description header field 314 [RFC2045], the following syntax is used: 316 description = "Content-Description:" unstructured CRLF 318 The syntax is extended above to allow UTF-8 in all 319 header fields. 321 Note, however, this does not remove any constraint on the character 322 set of protocol elements; for instance, all the allowed values for 323 timezone in the Date: headers are still expressed in ASCII. And 324 also, none of this revised syntax changes what is allowed in a 325 , which will still remain in pure ASCII. 327 4.4. Change on addr-spec Syntax 329 Internationalized email addresses are represented in UTF-8. Thus, 330 all header fields containing es are updated to permit UTF-8 331 addresses. 333 mailbox = name-addr / addr-spec / uAddr-Spec 335 angle-addr =/ [CFWS] "<" uAddr-Spec">" [CFWS] / 336 obs-angle-addr 338 uAddr-Spec = uLocal-Part "@" uDomain 340 uLocal-Part = uDot-String / uQuoted-String 342 uQuoted-String = DQUOTE *uQcontent DQUOTE uDomain 343 = (sub-uDomain 1*("." sub-uDomain)) / address-literal 345 Below are a few examples of possible representations. 347 "DISPLAY_NAME" 348 ; traditional mailbox format 349 "DISPLAY_NAME" 350 ; message will bounce if UTF8SMTPbis extension is not supported 351 352 ; without DISPLAY_NAME and quoted string 353 ; message will bounce if UTF8SMTPbis extension is not supported 355 4.5. Trace Field Syntax 357 "For" fields containing internationalized addresses are allowed, by 358 use of the new uFor syntax. UTF-8 information may be needed in 359 Received fields. Such information is therefore allowed to preserve 360 the integrity of those fields. The uFor syntax retains the original 361 UTF-8 email address between email address internationalization EAI- 362 aware MTAs. 364 The "Return-Path" header field provides the email return address in 365 the mail delivery. Thus, the header is augmented to carry UTF-8 366 addresses (see the revised syntax of in Section 4.4 of 367 this document). This will not break the rule of trace field 368 integrity, because the header field is added at the last MTA and 369 described in [RFC5321]. 371 The on "Received:" syntax is augmented to allow UTF-8 372 email address in the "For" field. is augmented to 373 include UTF-8 email address. In order to allow UTF-8 email addresses 374 in an , is added to . 376 item-value =/ uAddr-Spec 378 4.6. message/global 380 Internationalized messages must only be transmitted as authorized by 381 [I-D.yao-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 contains a message that 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 would treat 393 it as "application/octet-stream" as described in Section 5.2.4 of 394 [RFC2046].) 396 Type name: message 398 Subtype name: global 400 Required parameters: none 402 Optional parameters: none 404 Encoding considerations: Any content-transfer-encoding is permitted. 405 The 8-bit or binary content-transfer-encodings are recommended 406 where permitted. 408 Security considerations: See Section 5. 410 Interoperability considerations: The media type provides 411 functionality similar to the message/rfc822 content type for email 412 messages with international email headers. When there is a need 413 to embed or return such content in another message, there is 414 generally an option to use this media type and leave the content 415 unchanged or down-convert the content to message/rfc822. Both of 416 these choices will interoperate with the installed base, but with 417 different properties. Systems unaware of international headers 418 will typically treat a message/global body part as an unknown 419 attachment, while they will understand the structure of a message/ 420 rfc822. However, systems that understand message/global will 421 provide functionality superior to the result of a down-conversion 422 to message/rfc822. The most interoperable choice depends on the 423 deployed software. 425 Published specification: RFC XXXX 427 Applications that use this media type: SMTP servers and email 428 clients that support multipart/report generation or parsing. 429 Email clients which forward messages with international headers as 430 attachments. 432 Additional information: 434 Magic number(s): none 436 File extension(s): The extension ".u8msg" is suggested. 438 Macintosh file type code(s): A uniform type identifier (UTI) of 439 "public.utf8-email-message" is suggested. This conforms to 440 "public.message" and "public.composite-content", but does not 441 necessarily conform to "public.utf8-plain-text". 443 Person & email address to contact for further information: See the 444 Author's Address section of this document. 446 Intended usage: COMMON 448 Restrictions on usage: This is a structured media type which embeds 449 other MIME media types. The 8-bit or binary content-transfer- 450 encoding MUST be used unless this media type is sent over a 7-bit- 451 only transport. 453 Author: See the Author's Address section of this document. 455 Change controller: IETF Standards Process 457 5. Security Considerations 459 If a user has a non-ASCII mailbox address and an ASCII mailbox 460 address, a digital certificate that identifies that user may have 461 both addresses in the identity. Having multiple email addresses as 462 identities in a single certificate is already supported in PKIX 463 (Public Key Infrastructure for X.509 Certificates) and OpenPGP. 465 Because UTF-8 often requires several octets to encode a single 466 character, internationalized local parts may cause mail addresses to 467 become longer. As specified in [RFC5322], each line of characters 468 MUST be no more 998 octets, excluding the CRLF. 470 Because internationalized local parts may cause email addresses to be 471 longer, processes that parse, store, or handle email addresses or 472 local parts must take extra care not to overflow buffers, truncate 473 addresses, or exceed storage allotments. Also, they must take care, 474 when comparing, to use the entire lengths of the addresses. 476 In this specification, a user could provide an ASCII alternative 477 address for a non-ASCII address. However, it is possible these two 478 addresses go to different mailboxes, or even different people. This 479 configuration may be based on a user's personal choice or on 480 administration policy. We recognize that if ASCII and non-ASCII 481 email is delivered to two different destinations, based on MTA 482 capability, this may violate the principle of least astonishment, but 483 this is not a "protocol problem". 485 The security impact of UTF-8 headers on email signature systems such 486 as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is 487 discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14. 489 6. IANA Considerations 491 IANA has registered the message/global MIME type using the 492 registration form contained in Section 4.4. 494 7. Acknowledgements 496 This document incorporates many ideas first described in Internet- 497 Draft form by Paul Hoffman, although many details have changed from 498 that earlier work. 500 The author especially thanks Jeff Yeh for his efforts and 501 contributions on editing previous versions. 503 Most of the content of this document is provided by John C Klensin. 504 Also, some significant comments and suggestions were received from 505 Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris 506 Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team 507 (Joint Engineering Team) and were incorporated into the document. 508 The editor sincerely thanks them for their contributions. 510 8. Edit history 512 This section is used for tracking the update of this document. Will 513 be removed after finalize. 515 8.1. draft-ietf-eai-rfc5335bis-00 517 1. Applied Errata suggested by Alfred Hoenes. 519 2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322]. 521 3. Abrogate in ABNF of . 523 4. Revoke [RFC5504] from this document. 525 5. Upgrade some references from I-Ds to RFC. 527 8.2. draft-ietf-eai-rfc5335bis-01 529 1. Author name revised. 531 8.3. draft-ietf-eai-rfc5335bis-02 533 1. ABNF revised. 535 9. References 537 9.1. Normative References 539 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 540 Framework for Internationalized 541 Email", 542 draft-ietf-eai-frmwrk-4952bis-02 (work 543 in progress), July 2010. 545 [I-D.yao-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 546 for Internationalized Email Address", 547 draft-yao-eai-rfc5336bis-01 (work in 548 progress), July 2009. 550 [RFC1652] Klensin, J., Freed, N., Rose, M., 551 Stefferud, E., and D. Crocker, "SMTP 552 Service Extension for 8bit- 553 MIMEtransport", RFC 1652, July 1994. 555 [RFC2119] Bradner, S., "Key words for use in 556 RFCs to Indicate Requirement Levels", 557 BCP 14, RFC 2119, March 1997. 559 [RFC3629] Yergeau, F., "UTF-8, a transformation 560 format of ISO 10646", STD 63, 561 RFC 3629, November 2003. 563 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 564 Format for Network Interchange", 565 RFC 5198, March 2008. 567 [RFC5234] Crocker, D. and P. Overell, "Augmented 568 BNF for Syntax Specifications: ABNF", 569 STD 68, RFC 5234, January 2008. 571 [RFC5321] Klensin, J., "Simple Mail Transfer 572 Protocol", RFC 5321, October 2008. 574 [RFC5322] Resnick, P., Ed., "Internet Message 575 Format", RFC 5322, October 2008. 577 9.2. Informative References 579 [RFC2045] Freed, N. and N. Borenstein, 580 "Multipurpose Internet Mail Extensions 581 (MIME) Part One: Format of Internet 582 Message Bodies", RFC 2045, 583 November 1996. 585 [RFC2046] Freed, N. and N. Borenstein, 586 "Multipurpose Internet Mail Extensions 587 (MIME) Part Two: Media Types", 588 RFC 2046, November 1996. 590 [RFC2047] Moore, K., "MIME (Multipurpose 591 Internet Mail Extensions) Part Three: 592 Message Header Extensions for Non- 593 ASCII Text", RFC 2047, November 1996. 595 [RFC5504] Fujiwara, K. and Y. Yoneya, 596 "Downgrading Mechanism for Email 597 Address Internationalization", 598 RFC 5504, March 2009. 600 [RFC5721] Gellens, R. and C. Newman, "POP3 601 Support for UTF-8", RFC 5721, 602 February 2010. 604 [RFC5738] Resnick, P. and C. Newman, "IMAP 605 Support for UTF-8", RFC 5738, 606 March 2010. 608 Authors' Addresses 610 Abel YANG 611 TWNIC 612 4F-2, No. 9, Sec 2, Roosvelt Rd. 613 Taipei, 100 614 Taiwan 616 Phone: +886 2 23411313 ext 505 617 EMail: abelyang@twnic.net.tw 619 Shawn Steele 620 Microsoft 622 EMail: Shawn.Steele@microsoft.com