idnits 2.17.1 draft-ietf-eai-rfc5335bis-01.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 is 1 instance 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 (July 12, 2010) is 5030 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) == Unused Reference: 'RFC5721' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC5738' is defined on line 594, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-eai-frmwrk-4952bis-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 (~~), 6 warnings (==), 9 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 July 12, 2010 7 (if approved) 8 Intended status: Standards Track 9 Expires: January 13, 2011 11 Internationalized Email Headers 12 draft-ietf-eai-rfc5335bis-01 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 January 13, 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 . . . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8.1. draft-ietf-eai-rfc5335bis-00 . . . . . . . . . . . . . . . 12 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 1.1. Role of This Specification 87 Full internationalization of electronic mail requires several 88 capabilities: 90 o The capability to transmit non-ASCII content, provided for as part 91 of the basic MIME specification [RFC2045], [RFC2046]. 93 o The capability to use international characters in envelope 94 addresses, discussed in [I-D.ietf-eai-frmwrk-4952bis] and 95 specified in [I-D.yao-eai-rfc5336bis]. 97 o The capability to express those addresses, and information related 98 to them and based on them, in mail header fields, defined in this 99 document. 101 This document specifies an variant of Internet mail that permits the 102 use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the 103 base form for Internet email header fields. This form is permitted 104 in transmission, if authorized by the SMTP extension specified in 105 [I-D.yao-eai-rfc5336bis] or by other transport mechanisms capable of 106 processing it. 108 1.2. Relation to Other Standards 110 This document updates Section 6.4 of [RFC2045]. It removes the 111 blanket ban on applying a content-transfer-encoding to all subtypes 112 of message/, and instead specifies that a composite subtype MAY 113 specify whether or not a content-transfer-encoding can be used for 114 that subtype, with "cannot be used" as the default. 116 This document also updates [RFC5322] and MIME ([RFC2045]), and people 117 who participate in the experiment have to swich to this document. 119 Allowing use of a content-transfer-encoding on subtypes of messages 120 is not limited to transmissions that are authorized by the SMTP 121 extension specified in [I-D.yao-eai-rfc5336bis]. Message/global (see 122 Section 4.6) permits use of a content-transfer-encoding. 124 2. Background and History 126 Mailbox names often represent the names of human users. Many of 127 these users throughout the world have names that are not normally 128 expressed with just the ASCII repertoire of characters, and would 129 like to use more or less their real names in their mailbox names. 130 These users are also likely to use non-ASCII text in their common 131 names and subjects of email messages, both received and sent. This 132 protocol specifies UTF-8 as the encoding to represent email header 133 field bodies. 135 The traditional format of email messages [RFC5322] allows only ASCII 136 characters in the header fields of messages. This prevents users 137 from having email addresses that contain non-ASCII characters. It 138 further forces non-ASCII text in common names, comments, and in free 139 text (such as in the Subject: field) to be encoded (as required by 140 MIME format [RFC2047]). This specification describes a change to the 141 email message format that is related to the SMTP message transport 142 change described in the associated document 143 [I-D.ietf-eai-frmwrk-4952bis] and [I-D.yao-eai-rfc5336bis], and that 144 allows non-ASCII characters in most email header fields. These 145 changes affect SMTP clients, SMTP servers, mail user agents (MUAs), 146 list expanders, gateways to other media, and all other processes that 147 parse or handle email messages. 149 As specified in [I-D.yao-eai-rfc5336bis], an SMTP protocol extension 150 "UTF8SMTPbis" is used to prevent the transmission of messages with 151 UTF-8 header fields to systems that cannot handle such messages. 152 [[Note in Draft: Keyword related to UTF8SMTP will be decided by WG 153 before publication.]] 155 Use of this SMTP extension helps prevent the introduction of such 156 messages into message stores that might misinterpret, improperly 157 display, or mangle such messages. It should be noted that using an 158 ESMTP extension does not prevent transferring email messages with 159 UTF-8 header fields to other systems that use the email format for 160 messages and that may not be upgraded, such as unextended POP and 161 IMAP servers. Changes to these protocols to handle UTF-8 header 162 fields are addressed in [RFC5721]-bis and [RFC5738]-bis. 164 The objective for this protocol is to allow UTF-8 in email header 165 fields. 167 3. Terminology 169 A plain ASCII string is also a valid UTF-8 string; see [RFC3629]. In 170 this document, ordinary ASCII characters are UTF-8 characters if they 171 are in headers which contain s. 173 Unless otherwise noted, all terms used here are defined in [RFC5321], 174 [RFC5322], [I-D.ietf-eai-frmwrk-4952bis],or [I-D.yao-eai-rfc5336bis]. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 4. Changes on Message Header Fields 182 SMTP clients can send header fields in UTF-8 format, if the 183 UTF8SMTPbis extension is advertised by the SMTP server or is 184 permitted by other transport mechanisms. 186 This protocol does NOT change the [RFC5322] rules for defining header 187 field names. The bodies of header fields are allowed to contain 188 UTF-8 characters, but the header field names themselves must contain 189 only ASCII characters. 191 To permit UTF-8 characters in field values, the header definition in 192 [RFC5322] must be extended to support the new format. The following 193 ABNF is defined to substitute those definitions in [RFC5322]. 195 The syntax rules not covered in this section remain as defined in 196 [RFC5322]. 198 4.1. UTF-8 Syntax and Normalization 200 UTF-8 characters can be defined in terms of octets using the 201 following ABNF [RFC5234], taken from [RFC3629]: 203 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 205 UTF8-2 = %xC2-DF UTF8-tail 207 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 208 %xE1-EC 2(UTF8-tail) / 209 %xED %x80-9F UTF8-tail / 210 %xEE-EF 2(UTF8-tail) 212 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 213 %xF1-F3 3( UTF8-tail ) / 214 %xF4 %x80-8F 2( UTF8-tail ) 216 UTF8-tail = %x80-BF 218 These are normatively defined in [RFC3629], but kept in this document 219 for reasons of convenience. 221 See [RFC5198] for a discussion of normalization; the use of 222 normalization form NFC is RECOMMENDED. Actually, if one is going to 223 do internationalization properly, one of the most often-cited goals 224 is to permit people to spell their names correctly. Since many 225 mailbox local parts reflect personal names, that principle applies as 226 well. And NFKC is not recommended because it may lose information 227 that is needed to correctly spell some names except in unusual 228 circumstances. 230 4.2. Changes on MIME Headers 232 This specification updates Section 6.4 of [RFC2045]. [RFC2045] 233 prohibits applying a content-transfer-encoding to all subtypes of 234 message/. This specification relaxes the rule -- it allows newly 235 defined MIME types to permit content-transfer-encoding, and it allows 236 content-transfer-encoding for message/global (see Section 4.6). 238 Background: Normally, transfer of message/global will be done in 239 8-bit-clean channels, and body parts will have "identity" encodings, 240 that is, no decoding is necessary. In the case where a message 241 containing a message/global is downgraded from 8-bit to 7-bit as 242 described in [RFC1652], an encoding may be applied to the message; if 243 the message travels multiple times between a 7-bit environment and an 244 environment implementing UTF8SMTPbis, multiple levels of encoding may 245 occur. This is expected to be rarely seen in practice, and the 246 potential complexity of other ways of dealing with the issue are 247 thought to be larger than the complexity of allowing nested encodings 248 where necessary. 250 4.3. Syntax Extensions to RFC 5322 252 The following rules are intended to extend the corresponding rules in 253 [RFC5322] in order to allow UTF-8 characters. 255 FWS = 257 CFWS = 259 ctext =/ UTF8-xtra-char 261 utext =/ UTF8-xtra-char 263 comment = "(" *([FWS] utf8-ccontent) [FWS] ")" 265 word = utf8-atom / utf8-quoted-string 267 This means that all the [RFC5322] constructs that build upon these 268 will permit UTF-8 characters, including comments and quoted strings. 269 We do not change the syntax of in order to allow UTF-8 270 characters in . This would also allow UTF-8 characters in 271 , which is not allowed due to the limitation described in 272 Section 4.5. Instead, is added to meet this 273 requirement. 275 utf8-text = %d1-9 / ; all UTF-8 characters except 276 %d11-12 / ; US-ASCII NUL, CR, and LF 277 %d14-127 / 278 UTF8-xtra-char 280 utf8-quoted-pair = ("\" utf8-text) / obs-qp 282 utf8-qcontent = utf8-qtext / utf8-quoted-pair 284 utf8-quoted-string = [CFWS] 285 DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE 286 [CFWS] 288 utf8-ccontent = ctext / utf8-quoted-pair / comment 289 utf8-qtext = qtext / UTF8-xtra-char 291 utf8-atext = ALPHA / DIGIT / 292 "!" / "#" / ; Any character except 293 "$" / "%" / ; controls, SP, and specials. 294 "&" / "'" / ; Used for atoms. 295 "*" / "+" / 296 "-" / "/" / 297 "=" / "?" / 298 "^" / "_" / 299 "`" / "{" / 300 "|" / "}" / 301 "~" / 302 UTF8-xtra-char 304 utf8-atom = [CFWS] 1*utf8-atext [CFWS] 306 utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] 308 utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) 310 qcontent = utf8-qcontent 312 To allow the use of UTF-8 in a Content-Description header field 313 [RFC2045], the following syntax is used: 315 description = "Content-Description:" unstructured CRLF 317 The syntax is extended above to allow UTF-8 in all 318 header fields. 320 Note, however, this does not remove any constraint on the character 321 set of protocol elements; for instance, all the allowed values for 322 timezone in the Date: headers are still expressed in ASCII. And 323 also, none of this revised syntax changes what is allowed in a 324 , which will still remain in pure ASCII. 326 4.4. Change on addr-spec Syntax 328 Internationalized email addresses are represented in UTF-8. Thus, 329 all header fields containing es are updated to permit UTF-8 330 addresses. 332 mailbox = name-addr / addr-spec / utf8-addr-spec 334 angle-addr =/ [CFWS] "<" utf8-addr-spec">" [CFWS] / 335 obs-angle-addr 337 utf8-addr-spec = utf8-local-part "@" utf8-domain 339 utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part 341 utf8-domain = utf8-dot-atom / domain-literal / obs-domain 343 Below are a few examples of possible representations. 345 "DISPLAY_NAME" 346 ; traditional mailbox format 347 "DISPLAY_NAME" 348 ; message will bounce if UTF8SMTPbis extension is not supported 349 350 ; without DISPLAY_NAME and quoted string 351 ; message will bounce if UTF8SMTPbis extension is not supported 353 4.5. Trace Field Syntax 355 "For" fields containing internationalized addresses are allowed, by 356 use of the new uFor syntax. UTF-8 information may be needed in 357 Received fields. Such information is therefore allowed to preserve 358 the integrity of those fields. The uFor syntax retains the original 359 UTF-8 email address between email address internationalization EAI- 360 aware MTAs. 362 The "Return-Path" header field provides the email return address in 363 the mail delivery. Thus, the header is augmented to carry UTF-8 364 addresses (see the revised syntax of in Section 4.4 of 365 this document). This will not break the rule of trace field 366 integrity, because the header field is added at the last MTA and 367 described in [RFC5321]. 369 The on "Received:" syntax is augmented to allow UTF-8 370 email address in the "For" field. is augmented to 371 include UTF-8 email address. In order to allow UTF-8 email addresses 372 in an , is added to . 374 item-value =/ utf8-addr-spec 376 4.6. message/global 378 Internationalized messages must only be transmitted as authorized by 379 [I-D.yao-eai-rfc5336bis] or within a non-SMTP environment which 380 supports these messages. A message is a "message/global message", if 382 o it contains UTF-8 header values as specified in this document, or 384 o it contains UTF-8 values in the headers fields of body parts. 386 The type message/global is similar to message/rfc822, except that it 387 contains a message that can contain UTF-8 characters in the headers 388 of the message or body parts. If this type is sent to a 7-bit-only 389 system, it has to be encoded in MIME [RFC2045]. (Note that a system 390 compliant with MIME that doesn't recognize message/global would treat 391 it as "application/octet-stream" as described in Section 5.2.4 of 392 [RFC2046].) 394 Type name: message 396 Subtype name: global 398 Required parameters: none 400 Optional parameters: none 402 Encoding considerations: Any content-transfer-encoding is permitted. 403 The 8-bit or binary content-transfer-encodings are recommended 404 where permitted. 406 Security considerations: See Section 5. 408 Interoperability considerations: The media type provides 409 functionality similar to the message/rfc822 content type for email 410 messages with international email headers. When there is a need 411 to embed or return such content in another message, there is 412 generally an option to use this media type and leave the content 413 unchanged or down-convert the content to message/rfc822. Both of 414 these choices will interoperate with the installed base, but with 415 different properties. Systems unaware of international headers 416 will typically treat a message/global body part as an unknown 417 attachment, while they will understand the structure of a message/ 418 rfc822. However, systems that understand message/global will 419 provide functionality superior to the result of a down-conversion 420 to message/rfc822. The most interoperable choice depends on the 421 deployed software. 423 Published specification: RFC XXXX 425 Applications that use this media type: SMTP servers and email 426 clients that support multipart/report generation or parsing. 427 Email clients which forward messages with international headers as 428 attachments. 430 Additional information: 432 Magic number(s): none 434 File extension(s): The extension ".u8msg" is suggested. 436 Macintosh file type code(s): A uniform type identifier (UTI) of 437 "public.utf8-email-message" is suggested. This conforms to 438 "public.message" and "public.composite-content", but does not 439 necessarily conform to "public.utf8-plain-text". 441 Person & email address to contact for further information: See the 442 Author's Address section of this document. 444 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 MUST be used unless this media type is sent over a 7-bit- 449 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) and OpenPGP. 463 Because UTF-8 often requires several octets to encode a single 464 character, internationalized local parts may cause mail addresses to 465 become longer. As specified in [RFC5322], each line of characters 466 MUST be no more 998 octets, excluding the CRLF. 468 Because internationalized local parts may cause email addresses to be 469 longer, processes that parse, store, or handle email addresses or 470 local parts must take extra care not to overflow buffers, truncate 471 addresses, or exceed storage allotments. Also, they must take care, 472 when comparing, to use the 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 9. References 527 9.1. Normative References 529 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 530 Framework for Internationalized 531 Email", 532 draft-ietf-eai-frmwrk-4952bis-01 (work 533 in progress), July 2010. 535 [I-D.yao-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 536 for Internationalized Email Address", 537 draft-yao-eai-rfc5336bis-00 (work in 538 progress), July 2009. 540 [RFC1652] Klensin, J., Freed, N., Rose, M., 541 Stefferud, E., and D. Crocker, "SMTP 542 Service Extension for 8bit- 543 MIMEtransport", RFC 1652, July 1994. 545 [RFC2119] Bradner, S., "Key words for use in 546 RFCs to Indicate Requirement Levels", 547 BCP 14, RFC 2119, March 1997. 549 [RFC3629] Yergeau, F., "UTF-8, a transformation 550 format of ISO 10646", STD 63, 551 RFC 3629, November 2003. 553 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 554 Format for Network Interchange", 555 RFC 5198, March 2008. 557 [RFC5234] Crocker, D. and P. Overell, "Augmented 558 BNF for Syntax Specifications: ABNF", 559 STD 68, RFC 5234, January 2008. 561 [RFC5321] Klensin, J., "Simple Mail Transfer 562 Protocol", RFC 5321, October 2008. 564 [RFC5322] Resnick, P., Ed., "Internet Message 565 Format", RFC 5322, October 2008. 567 9.2. Informative References 569 [RFC2045] Freed, N. and N. Borenstein, 570 "Multipurpose Internet Mail Extensions 571 (MIME) Part One: Format of Internet 572 Message Bodies", RFC 2045, 573 November 1996. 575 [RFC2046] Freed, N. and N. Borenstein, 576 "Multipurpose Internet Mail Extensions 577 (MIME) Part Two: Media Types", 578 RFC 2046, November 1996. 580 [RFC2047] Moore, K., "MIME (Multipurpose 581 Internet Mail Extensions) Part Three: 582 Message Header Extensions for Non- 583 ASCII Text", RFC 2047, November 1996. 585 [RFC5504] Fujiwara, K. and Y. Yoneya, 586 "Downgrading Mechanism for Email 587 Address Internationalization", 588 RFC 5504, March 2009. 590 [RFC5721] Gellens, R. and C. Newman, "POP3 591 Support for UTF-8", RFC 5721, 592 February 2010. 594 [RFC5738] Resnick, P. and C. Newman, "IMAP 595 Support for UTF-8", RFC 5738, 596 March 2010. 598 Authors' Addresses 600 Abel YANG 601 TWNIC 602 4F-2, No. 9, Sec 2, Roosvelt Rd. 603 Taipei, 100 604 Taiwan 606 Phone: +886 2 23411313 ext 505 607 EMail: abelyang@twnic.net.tw 609 Shawn Steele 610 Microsoft 612 EMail: Shawn.Steele@microsoft.com