idnits 2.17.1 draft-ietf-eai-utf8headers-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 598. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 10, 2007) is 6284 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) == Unused Reference: 'ASCII' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC3864' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC4646' is defined on line 546, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-smtpext (ref. 'EAI-SMTP-extension') == Outdated reference: A later version (-07) exists of draft-ietf-eai-mailinglist-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-mailinglist (ref. 'EAI-mailing-list') ** Downref: Normative reference to an Informational draft: draft-ietf-eai-framework (ref. 'EAI-overview') ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-01 -- Obsolete informational reference (is this intentional?): RFC 4646 (Obsoleted by RFC 5646) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yeh, Ed. 3 Internet-Draft TWNIC 4 Expires: August 14, 2007 February 10, 2007 6 Internationalized Email Headers 7 draft-ietf-eai-utf8headers-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 14, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Full internationalization of electronic mail requires not only the 41 capability to transmit non-ASCII content, to encode selected 42 information in specific header fields, and to use non-ASCII 43 characters in envelope addresses. It also requires being able to 44 express those addresses and information based on them in mail header 45 fields. This document specifies the use of Unicode encoded in UTF-8, 46 rather than ASCII, as the base form for Internet email header field 47 bodies. This form is permitted in transmission only if authorized by 48 an SMTP extension, as specified in an associated specification. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 54 2. Background and History . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Pre-requirement . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 58 5.1. UTF8 Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Syntax extensions to RFC 2822 . . . . . . . . . . . . . . 6 60 5.3. Change on addr-spec syntax . . . . . . . . . . . . . . . . 8 61 5.4. Trace field syntax . . . . . . . . . . . . . . . . . . . . 8 62 6. Additional issues . . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Mailing list header fields . . . . . . . . . . . . . . . . 9 64 6.2. MIME headers . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 10. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. draft-ietf-eai-utf8header-02 => 70 draft-ietf-eai-utf8header-03 . . . . . . . . . . . . . . . 10 71 10.2. draft-ietf-eai-utf8header-01 => 72 draft-ietf-eai-utf8header-02 . . . . . . . . . . . . . . . 11 73 10.3. draft-ietf-eai-utf8header-00 => 74 draft-ietf-eai-utf8header-01 . . . . . . . . . . . . . . . 11 75 10.4. draft-yeh-ima-utf8header-01 => 76 draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 11 77 10.5. draft-yeh-ima-utf8header-00 => 78 draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 11 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property and Copyright Statements . . . . . . . . . . 14 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]. 94 o The capability to encode selected information in specific header 95 fields, provided for as another part of the MIME specification 96 [RFC2047]. 97 o The capability to use international characters in envelope 98 addresses, discussed in [EAI-overview] and specified in 99 [EAI-SMTP-extension]. And, finally, 100 o The capability to express those addresses, and information related 101 to and based on them, in mail header fields, defined in this 102 document. 103 o The capability to use international characters in other headers, 104 but only as expressly permitted herein, or in future extensions. 106 This document specifies the use of Unicode encoded in UTF-8 107 [RFC3629], rather than ASCII, as the base form for Internet email 108 header fields. This form is permitted in transmission, if authorized 109 by the SMTP extension specified in [EAI-SMTP-extension] or by other 110 transport mechanisms capable of processing it. 112 2. Background and History 114 Mailbox names often represent the names of human users. Many of 115 these users throughout the world have names that are not normally 116 represented with just the ASCII repertoire of characters, and would 117 more or less like to use their real names in their mailbox names. 118 These users are also likely to use non-ASCII text in their common 119 names and subjects of email messages, both in what they send and what 120 they receive. This protocol specifies UTF-8 as the encoding to 121 represent email header field bodies. 123 The traditional format of email messages [RFC2822] allows only ASCII 124 characters in the header fields of messages. This prevents users 125 from having email addresses that contain non-ASCII characters. It 126 further forces non-ASCII text in common names, comments, and in free 127 text (such as in the Subject: field) to be in MIME format [RFC2047]. 128 This specification describes a change to the email message format 129 that is related to the SMTP message transport change described in the 130 associated specifications [EAI-overview] and [EAI-SMTP-extension], 131 and that allows non-ASCII characters throughout email header fields. 133 These changes affect SMTP clients, SMTP servers, mail user agents 134 (MUAs), list expanders and and gateways to other media. 136 As specified in [EAI-SMTP-extension], an SMTP protocol extension 137 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 138 header fields to systems that cannot handle such messages. 140 Use of this SMTP extension helps prevent against the introduction of 141 such messages into message stores that might misrepresent or mangle 142 such messages. It should be noted that using an ESMTP extension does 143 not prevent against transferring email messages with UTF-8 header 144 fields to other systems that use the email format for messages and 145 that may not be upgraded, such as the POP and IMAP protocols. Those 146 protocols also need to be changed in order to handle stored messages 147 that have UTF-8 header fields. 149 The objective for this protocol is to allow UTF-8 in email header 150 fields. Issues about how to handle messages that contain UTF-8 151 header fields but are proposed to be delivered to systems that have 152 not been upgraded to support this capability are discussed elsewhere, 153 particularly in [EAI-downgrading]. 155 3. Terminology 157 In this document, header fields are "UTF-8 headers" if the bodies of 158 those headers contain UTF-8 characters. 160 Unless otherwise noted, all terms used here are defined in [RFC2821] 161 or [RFC2822] or in [EAI-overview]. 163 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 164 and "MAY" in this document are to be interpreted as described in RFC 165 2119 [RFC2119]. 167 This document is being discussed on the ima mailing list. See 168 https://www1.ietf.org/mailman/listinfo/ima for information about 169 subscribing. The list's archive is at 170 http://www1.ietf.org/mail-archive/web/ima/index.html. 172 4. Pre-requirement 174 The use of UTF-8 header fields is dependent on the use of an SMTP 175 extension named "UTF8SMTP" or of similar capabilities in other 176 transports. 178 That protocol is defined in [EAI-SMTP-extension]. If that extension 179 is not supported, UTF-8 header fields MUST NOT be transmitted by 180 SMTP. 182 Sending MUAs conforming to this specification MUST encode all header 183 fields in UTF-8. No other direct encodings (like Big-5) are allowed. 184 Although there is nothing wrong with the continued use of [RFC2047], 185 it is not recommended in this document. 187 5. Changes on Message Header Fields 189 SMTP client can send header fields in UTF-8 format, if the UTF8SMTP 190 extension advertised by SMTP server or as permitted by other 191 transport mechanisms. 193 This protocol does NOT change the definition of header field names. 194 That is, only the bodies of header fields are allowed to have UTF-8 195 characters; the rules in RFC 2822 for header names are not changed. 196 To be able to do so, the header definition in RFC 2822 must extended 197 to support new format. That following ABNF is defined to substitute 198 those definition in RFC 2822. 200 For those syntax rules not referred in this section remains as the 201 original definition in RFC 2822. 203 5.1. UTF8 Syntax 205 The use of UTF8 characters are defined as following. 207 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 209 UTF8-2 = %xC2-DF UTF8-tail 211 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 212 %xE1-EC 2(UTF8-tail) / 213 %xED %x80-9F UTF8-tail / 214 %xEE-EF 2(UTF8-tail) 216 UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / 217 %xF1-F7 3(UTF8-tail) 219 UTF8-tail = %x80-BF 221 These are taken from FRC 3629, but kept in this document for reasons 222 of convenience. 223 [Note in draft: Whether normalizing is needed or not will be place in 224 here.] 226 5.2. Syntax extensions to RFC 2822 228 The following rules are intended to extend the corresponding rules in 229 RFC 2822 to allow UTF8 characters. 231 ctext = NO-WS-CTL / ; all of except 232 %d33-39 / ; SP, HTAB, "(", ")" 233 %d42-91 / ; and "\" 234 %d93-126 / 235 UTF8-xtra-char 237 utext = NO-WS-CTL / ; Non white space controls 238 %d33-126 / ; The rest of US-ASCII 239 UTF8-xtra-char 241 comment = "(" *([FWS] utf8-ccontent) [FWS] ")" 243 word = utf8-atom / utf8-quoted-string 245 This means that all the RFC 2822 constructs that build upon these 246 will permit UTF-8 characters, including comments and quoted strings. 247 Besides, in order to allow UTF8 characters in we have to 248 change the syntax of . However, it will also lead to 249 allow UTF8 characters, which is not allowed due to the limitation 250 described in Section 5.4. So is added to meet this 251 requirement. 253 utf8-text = %d1-9 / ; all UTF-8 characters except 254 %d11-12 / ; US-ASCII NUL, CR and LF 255 %d14-127 / 256 UTF8-xtra-char 258 utf8-quoted-pair = ("\" utf8-text) / obs-qp 260 utf8-qcontent = utf8-qtext / utf8-quoted-pair 262 utf8-quoted-string = [CFWS] 263 DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE 264 [CFWS] 266 utf8-ccontent = ctext / utf8-quoted-pair / comment 268 utf8-qtext = NO-WS-CTL / ; all of except 269 %d33 / ; The rest of the US-ASCII 270 %d35-91 / ; characters not including "\" 271 %d93-126 / ; or the quote character 272 UTF8-xtra-char 274 utf8-atext = ALPHA / DIGIT / 275 "!" / "#" / ; Any character except 276 "$" / "%" / ; controls, SP, and specials. 277 "&" / "'" / ; Used for atoms 278 "*" / "+" / 279 "-" / "/" / 280 "=" / "?" / 281 "^" / "_" / 282 "`" / "{" / 283 "|" / "}" / 284 "~" / 285 UTF8-xtra-char 287 utf8-atom = [CFWS] 1*utf8-atext [CFWS] 289 utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] 291 utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) 293 [NOTE IN DRAFT: If any header needs to be restricted to disallow 294 this, please raise the issue on the mailing list.] 295 Note, however, this does not remove any constraint on the character 296 set of protocol elements; for instance, all the allowed values for 297 timezone in the Date: headers are still expressed in ASCII. And 298 also, none of this revised syntax affects what is allowed in a 299 , which will still remain in pure ASCII. 301 5.3. Change on addr-spec syntax 303 In this specification, internationalized email address will be 304 presented in UTF-8. Thus, all header fields involving es 305 may be different from traditional ones. There might be UTF8SMTP 306 unaware MTAs in the mail routing path. In that case, MTA may bounce 307 the message with reply code 550, or downgrade the non-ASCII contents 308 of all header bodies before continuing to send the message. The 309 downgrade process involve with a new ALT-ADDRESS parameter. When 310 downgrade occurs, the ALT-ADDRESS will be used for mail delivery 311 instead of the internationalized email address, the detail is 312 described in [EAI-downgrading]. 314 mailbox = name-addr / addr-spec / utf8-addr-spec 316 angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] 318 utf8-addr-spec = utf8-local-part "@" utf8-domain 320 utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part 322 utf8-domain = utf8-dot-atom / domain-literal / obs-domain 324 alt-address = [CFWS] "<" addr-spec ">" [CFWS] 326 Below list a few possible representation as example. 328 "DISPLAY_NAME" 329 ; traditional mailbox format 331 "DISPLAY_NAME" 332 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 333 ; message will bounce if UTF8SMTP extension is not supported 335 "DISPLAY_NAME" > 336 ; UTF8SMTP with ALT-ADDRESS parameter provided, 337 ; ALT-ADDRESS can be used if downgrade is necessary 339 5.4. Trace field syntax 341 Internationalized domain names in Received fields must be transmitted 342 in punycode form. "For" fields containing internationalized 343 addresses are prohibited, since subsequent downgrading would force 344 violating rules in RFC 2821 prohibiting altering existing Received 345 fields. With these two restrictions, there should be no need for 346 UTF-8 information in Received fields and such information is 347 prohibited to preserve the integrity of those fields. More 348 generally, UTF-8 information of any sort MUST NOT appear in Received 349 fields, even in comments within those fields. 351 The "Return-Path" header provides the email returning address in the 352 mail delivery. Thus, it MUST abel to carry UTF8 addresses (see the 353 revised syntax of in Section 5.2 of this document). 354 This will not break the rule of trace fied integrity, because it is 355 added at the last MTA. 357 6. Additional issues 359 This section identifies issues that are not covered as part of this 360 set of specifications, but that will need to be considered as part of 361 UTF8SMTP deployment. 363 6.1. Mailing list header fields 365 All mailing list and mail redistribution related header are discussed 366 in [EAI-mailing-list]. 368 6.2. MIME headers 370 The syntax of , as defined in RFC 2045, is 372 value = token / quoted-string 374 To be able to use UTF-8 characters in MIME headers, 375 syntax is extended as 377 qcontent = utf8-qtext / quoted-pair 379 In all those headers, such as Content-Type and Content-Dispoaition 380 [plus lots of others being defined in various other documents], which 381 make use of within as defined in [RFC2045] as 382 modified by [RFC2231], it will now be allowed to use s 383 containing UTF-8 characters (see the revised syntax of 384 in Section 5.2 of this document). 386 7. Security Considerations 388 If a user has a non-ASCII mailbox address and an ASCII mailbox 389 address, a digital certificate that identifies that user may have 390 both addresses in the identity. Having multiple email addresses as 391 identities in a single certificate is already supported in PKIX and 392 OpenPGP. 394 Because UTF-8 often requires several octets to encode a single 395 character, internationalized local parts may cause mail addresses to 396 become longer. As specified in RFC 2822, each line of characters 397 MUST be no more 998 octets, excluding the CRLF. 399 In this specification, a user could provide an ASCII alternative 400 address for a non-ASCII address. However, it is possible these two 401 address go to different mailbox, or even different persons. This 402 might not be a protocol problem, but the user's personal choice or 403 administration policy or even be a deliberate attempt to deceive or 404 cause confusion. 406 8. IANA considerations 408 There is no IANA considerations in this document. 410 9. Acknowledgements 412 This document was created by incorporating a good deal of material 413 from an old Internet Draft by Paul Hoffman [Hoffman-utf8-headers]. 414 While many of the concepts and details have changed, the 415 contributions from that draft are greatly appreciated. 417 Most of the content of this document is provided by John C Klensin. 418 Also some significant comments and suggestions were received from 419 Charles H. Lindsey, Kari Hurtta, Chris Newman, Yangwoo KO, Yoshiro 420 YONEYA, and other members of the JET team and were incorporated into 421 the document. The editor is much great thanks to their contribution 422 sincerely. 424 10. Edit history 426 This section is used for tracking the update of this document. Will 427 be removed after finalize. 429 10.1. draft-ietf-eai-utf8header-02 => draft-ietf-eai-utf8header-03 431 1. Editrial changes on terms and english. 432 2. ABNF revise. 433 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 434 "<" and ">". 435 4. Remove the "Header-Type" header. 436 5. Remove the content in IANA considerations since "Header-Type" is 437 removed. 439 10.2. draft-ietf-eai-utf8header-01 => draft-ietf-eai-utf8header-02 441 1. Editrial changes on terms and english. 442 2. Change the header name "UTF8SMTP" to "Header-Type", and ABNF 443 revise. 444 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 445 "[" and "]". 446 4. IANA considerations section rewrite into registeration templates 447 specified in RFC 3864. 449 10.3. draft-ietf-eai-utf8header-00 => draft-ietf-eai-utf8header-01 451 1. ABNF revise. 452 2. Terminology sync with overview document. 453 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 454 "{" and "}". 455 4. add IANA considerations to register the new 2822 header 456 "UTF8SMTP". 457 5. add Security considerations about relation of UTF8SMTP address to 458 ALT-ADDRESS. 460 10.4. draft-yeh-ima-utf8header-01 => draft-ietf-eai-utf8header-00 462 1. ABNF added. 463 2. Editrial changes. 464 3. Sent it as WG document. 466 10.5. draft-yeh-ima-utf8header-00 => draft-yeh-ima-utf8header-01 468 1. Section re-arranged. 469 2. Remove content are not below to this document. 471 11. References 473 11.1. Normative References 475 [ASCII] American National Standards Institute (formerly United 476 States of America Standards Institute), "USA Code for 477 Information Interchange", ANSI X3.4-1968, 1968. 479 ANSI X3.4-1968 has been replaced by newer versions with 480 slight modifications, but the 1968 version remains 481 definitive for the Internet. 483 [EAI-SMTP-extension] 484 Yao, J., Ed. and Wei. Mao, "SMTP extension for 485 internationalized email address", 486 draft-ietf-eai-smtpext-02.txt (work in progress), 487 July 2006. 489 [EAI-mailing-list] 490 Gellens, Randall., "Mailing Lists and Internationalized 491 Email Addresses", draft-ietf-eai-mailinglist-01.txt (work 492 in progress), January 2007. 494 [EAI-overview] 495 Klensin, J. and Y. Ko, "Overview and Framework of 496 Internationalized Email Address Delivery", 497 draft-ietf-eai-framework-05.txt (work in progress), 498 Feburary 2007. 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, March 1997. 503 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 504 Word Extensions: Character Sets, Languages, and 505 Continuations", RFC 2231, November 1997. 507 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 508 April 2001. 510 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 511 April 2001. 513 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 514 10646", STD 63, RFC 3629, November 2003. 516 11.2. Informative References 518 [EAI-downgrading] 519 YONEYA, Yoshiro., Ed. and Kazunori. Fujiwara, Ed., 520 "Downgrading mechanism for Internationalized eMail Address 521 (IMA)", draft-ietf-eai-downgrade-01.txt (work in 522 progress), June 2006. 524 [Hoffman-utf8-headers] 525 Hoffman, P., "SMTP Service Extensions or Transmission of 526 Headers in UTF-8 Encoding", 527 draft-hoffman-utf8headers-00.txt (work in progress), 528 December 2003. 530 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 531 Extensions (MIME) Part One: Format of Internet Message 532 Bodies", RFC 2045, November 1996. 534 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 535 Extensions (MIME) Part Two: Media Types", RFC 2046, 536 November 1996. 538 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 539 Part Three: Message Header Extensions for Non-ASCII Text", 540 RFC 2047, November 1996. 542 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 543 Procedures for Message Header Fields", BCP 90, RFC 3864, 544 September 2004. 546 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 547 Languages", BCP 47, RFC 4646, September 2006. 549 Author's Address 551 Jeff Yeh (editor) 552 TWNIC 553 4F-2, No. 9, Sec 2, Roosvelt Rd. 554 Taipei, 100 555 Taiwan 557 Phone: +886 2 23411313 ext 506 558 Email: jeff@twnic.net.tw 560 Full Copyright Statement 562 Copyright (C) The IETF Trust (2007). 564 This document is subject to the rights, licenses and restrictions 565 contained in BCP 78, and except as set forth therein, the authors 566 retain all their rights. 568 This document and the information contained herein are provided on an 569 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 570 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 571 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 572 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 573 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 576 Intellectual Property 578 The IETF takes no position regarding the validity or scope of any 579 Intellectual Property Rights or other rights that might be claimed to 580 pertain to the implementation or use of the technology described in 581 this document or the extent to which any license under such rights 582 might or might not be available; nor does it represent that it has 583 made any independent effort to identify any such rights. Information 584 on the procedures with respect to rights in RFC documents can be 585 found in BCP 78 and BCP 79. 587 Copies of IPR disclosures made to the IETF Secretariat and any 588 assurances of licenses to be made available, or the result of an 589 attempt made to obtain a general license or permission for the use of 590 such proprietary rights by implementers or users of this 591 specification can be obtained from the IETF on-line IPR repository at 592 http://www.ietf.org/ipr. 594 The IETF invites any interested party to bring to its attention any 595 copyrights, patents or patent applications, or other proprietary 596 rights that may cover technology that may be required to implement 597 this standard. Please address the information to the IETF at 598 ietf-ipr@ietf.org. 600 Acknowledgment 602 Funding for the RFC Editor function is provided by the IETF 603 Administrative Support Activity (IASA).