idnits 2.17.1 draft-ietf-eai-utf8headers-12.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 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 737. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 09, 2008) is 5767 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CFWS' is mentioned on line 339, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-12 ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-07 == Outdated reference: A later version (-09) exists of draft-ietf-eai-imap-utf8-03 == Outdated reference: A later version (-09) exists of draft-ietf-eai-pop-03 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Abel, Ed. 2 Internet-Draft TWNIC 3 Intended status: Experimental July 09, 2008 4 Expires: January 10, 2009 6 Internationalized Email Headers 7 draft-ietf-eai-utf8headers-12.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 January 10, 2009. 34 Abstract 36 Full internationalization of electronic mail requires not only the 37 capability to transmit non-ASCII content, to encode selected 38 information in specific header fields, and to use non-ASCII 39 characters in envelope addresses. It also requires being able to 40 express those addresses and information based on them in mail header 41 fields. This document specifies an experimental variant of Internet 42 mail that permits the use of Unicode encoded in UTF-8, rather than 43 ASCII, as the base form for Internet email header field bodies. This 44 form is permitted in transmission only if authorized by an SMTP 45 extension, as specified in an associated specification. And this 46 specification updates section 6.4 of [RFC2045] to conform with the 47 requirements. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 53 1.2. Relation to other standards . . . . . . . . . . . . . . . 3 54 2. Background and History . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 57 4.1. UTF8 Syntax and Normalization . . . . . . . . . . . . . . 5 58 4.2. Changes on MIME headers . . . . . . . . . . . . . . . . . 6 59 4.3. Syntax extensions to RFC 2822 . . . . . . . . . . . . . . 6 60 4.4. Change on addr-spec syntax . . . . . . . . . . . . . . . . 8 61 4.5. Trace field syntax . . . . . . . . . . . . . . . . . . . . 9 62 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. draft-ietf-eai-utf8header-12 . . . . . . . . . . . . . . . 12 68 8.2. draft-ietf-eai-utf8header-11 . . . . . . . . . . . . . . . 12 69 8.3. draft-ietf-eai-utf8header-10 . . . . . . . . . . . . . . . 12 70 8.4. draft-ietf-eai-utf8header-09 . . . . . . . . . . . . . . . 13 71 8.5. draft-ietf-eai-utf8header-08 . . . . . . . . . . . . . . . 13 72 8.6. draft-ietf-eai-utf8header-07 . . . . . . . . . . . . . . . 13 73 8.7. draft-ietf-eai-utf8header-06 . . . . . . . . . . . . . . . 13 74 8.8. draft-ietf-eai-utf8header-05 . . . . . . . . . . . . . . . 13 75 8.9. draft-ietf-eai-utf8header-04 . . . . . . . . . . . . . . . 13 76 8.10. draft-ietf-eai-utf8header-03 . . . . . . . . . . . . . . . 13 77 8.11. draft-ietf-eai-utf8header-02 . . . . . . . . . . . . . . . 14 78 8.12. draft-ietf-eai-utf8header-01 . . . . . . . . . . . . . . . 14 79 8.13. draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 14 80 8.14. draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 14 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Intellectual Property and Copyright Statements . . . . . . . . . . 17 87 1. Introduction 89 1.1. Role of this specification 91 Full internationalization of electronic mail requires several 92 capabilities: 94 o The capability to transmit non-ASCII content, provided for as part 95 of the basic MIME specification [RFC2045], [RFC2046]. 96 o The capability to use international characters in envelope 97 addresses, discussed in [RFC4952] and specified in 98 [I-D.ietf-eai-smtpext]. 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 experimental variant of Internet mail that 104 permits the use of Unicode encoded in UTF-8 [RFC3629], rather than 105 ASCII, as the base form for Internet email header fields. This form 106 is permitted in transmission, if authorized by the SMTP extension 107 specified in [I-D.ietf-eai-smtpext] or by other transport mechanisms 108 capable of processing it. 110 1.2. Relation to other standards 112 This document updates section 6.4 of RFC 2045. 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 [RFC2822] and MIME ([RFC2045]), and the 119 fact that an experimental specification updates a standards-track 120 spec means that people who participate in the experiment have to 121 consider those standards updated. 123 Allowing of use a content-transfer-encoding on subtypes of messages 124 is not limited to transmissions, which are authorized by the SMTP 125 extension specified in [I-D.ietf-eai-smtpext]. Message/global 126 permits use of a content-transfer-encoding. 128 2. Background and History 130 Mailbox names often represent the names of human users. Many of 131 these users throughout the world have names that are not normally 132 expressed with just the ASCII repertoire of characters, and would 133 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 common 136 names and subjects of email messages, both in what they send and what 137 they receive. This protocol specifies UTF-8 as the encoding to 138 represent email header field bodies. 140 The traditional format of email messages [RFC2822] 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 common 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 document [RFC4952] and 148 [I-D.ietf-eai-smtpext], and that allows non-ASCII characters in most 149 email header fields. These changes affect SMTP clients, SMTP 150 servers, mail user agents (MUAs), list expanders, gateways to other 151 media, and all other processes that parse or handle email messages. 153 As specified in [I-D.ietf-eai-smtpext], an SMTP protocol extension 154 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 155 header fields to systems that cannot handle such messages. 157 Use of this SMTP extension helps prevents 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 transfering 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 [I-D.ietf-eai-pop] and 165 [I-D.ietf-eai-imap-utf8] . 167 The objective for this protocol is to allow UTF-8 in email header 168 fields. Issues such as how to handle messages containing UTF-8 169 header fields that have to be delivered to systems that have not been 170 upgraded to support this capability are discussed in 171 [I-D.ietf-eai-downgrade]. 173 3. Terminology 175 A plain ASCII string is also a valid UTF-8 string, see [RFC3629]. In 176 this document, ordinary ASCII characters are UTF-8 characters if they 177 are in headers which contain s. 179 Unless otherwise noted, all terms used here are defined in [RFC2821], 180 [RFC2822], [RFC4952], or [I-D.ietf-eai-smtpext]. 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 This document is discussed on the ima mailing list. See 187 https://www1.ietf.org/mailman/listinfo/ima for information about 188 subscribing. The list's archive is at 189 http://www1.ietf.org/mail-archive/web/ima/index.html. 191 4. Changes on Message Header Fields 193 SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP 194 extension is advertised by the SMTP server or as permitted by other 195 transport mechanisms. 197 This protocol does NOT change the [RFC2822] rules for defining header 198 field names. The bodies of header fields are allowed to contain 199 UTF-8 characters, but the header field names themselves must contain 200 only ASCII characters. 202 To permit UTF-8 characters in field values, the header definition in 203 [RFC2822] must be extended to support new format. The following ABNF 204 is defined to substitute those definition in [RFC2822]. 206 The syntax rules not covered in this section remain as defined in 207 [RFC2822]. 209 4.1. UTF8 Syntax and Normalization 211 UTF-8 characters can be defined in terms of octets using the 212 following ABNF, taken from [RFC3629]: 214 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 216 UTF8-2 = %xC2-DF UTF8-tail 218 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 219 %xE1-EC 2(UTF8-tail) / 220 %xED %x80-9F UTF8-tail / 221 %xEE-EF 2(UTF8-tail) 223 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / 224 %xF1-F3 3( UTF8-tail ) / 225 %xF4 %x80-8F 2( UTF8-tail ) 227 UTF8-tail = %x80-BF 228 These are normatively defined in [RFC3629], but kept in this document 229 for reasons of convenience. 231 See [RFC5198] for a discussion of normalization, the use of 232 normalization form NFC is RECOMMENDED. 234 4.2. Changes on MIME headers 236 This specification updates section 6.4 of [RFC2045]. [RFC2045] 237 prohibits applying a content-transfer-encoding to all subtypes of 238 message/. This specification relaxes the rule, allowing newly 239 defined MIME types to permit content-transfer-encoding, and permits 240 content-transfer-encoding for message/global (see Section 4.6). 242 Background: Normally, transfer of message/global will be done in 243 8-bit-clean channels, and body parts will have "identity" encodings, 244 that is, no decoding is necessary. In the case where a message 245 containing a message/global is downgraded from 8-bit to 7-bit as 246 described in [RFC1652]., an encoding may be applied to the message; 247 if the message travels multiple times between a 7-bit environment and 248 an environment implementing UTF8SMTP, multiple levels of encoding may 249 occur. This is expected to be rarely seen in practice, and the 250 potential complexity of other ways of dealing with the issue are 251 thought to be larger than the complexity of allowing nested encodings 252 where necessary. 254 4.3. Syntax extensions to RFC 2822 256 The following rules intended to extend the corresponding rules in 257 [RFC2822] to allow UTF8 characters. 259 FWS = 261 CFWS = 263 ctext =/ UTF8-xtra-char 265 utext =/ UTF8-xtra-char 267 comment = "(" *([FWS] utf8-ccontent) [FWS] ")" 269 word = utf8-atom / utf8-quoted-string 271 This means that all the [RFC2822] constructs that build upon these 272 will permit UTF-8 characters, including comments and quoted strings. 273 We do not change the syntax of in order to allow UTF8 274 characters in , because this would also allow UTF8 275 characters in , it is not allowed due to the limitation 276 described in Section 4.5. Instead, is added to meet 277 this requirement. 279 utf8-text = %d1-9 / ; all UTF-8 characters except 280 %d11-12 / ; US-ASCII NUL, CR and LF 281 %d14-127 / 282 UTF8-xtra-char 284 utf8-quoted-pair = ("\" utf8-text) / obs-qp 286 utf8-qcontent = utf8-qtext / utf8-quoted-pair 288 utf8-quoted-string = [CFWS] 289 DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE 290 [CFWS] 292 utf8-ccontent = ctext / utf8-quoted-pair / comment 293 utf8-qtext= qtext / UTF8-xtra-char 295 utf8-atext = ALPHA / DIGIT / 296 "!" / "#" / ; Any character except 297 "$" / "%" / ; controls, SP, and specials. 298 "&" / "'" / ; Used for atoms 299 "*" / "+" / 300 "-" / "/" / 301 "=" / "?" / 302 "^" / "_" / 303 "`" / "{" / 304 "|" / "}" / 305 "~" / 306 UTF8-xtra-char 308 utf8-atom = [CFWS] 1*utf8-atext [CFWS] 310 utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] 312 utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) 314 qcontent = utf8-qcontent 316 To allow the use of UTF-8 in a Content-Description header field 317 [RFC2045], the following syntax is used: 319 description = "Content-Description:" unstructured CRLF 320 The syntax is extended above to allow UTF-8 in all 321 header fields. 322 Note, however, this does not remove any constraint on the character 323 set of protocol elements; for instance, all the allowed values for 324 timezone in the Date: headers are still expressed in ASCII. And 325 also, none of this revised syntax changes what is allowed in a 326 , which will still remain in pure ASCII. 328 4.4. Change on addr-spec syntax 330 Internationalized email addresses are represented in UTF-8. Thus, 331 all header fields containing es are updated to permit UTF-8 332 as well as an additional, optional all-ascii alternate address. Note 333 that MSAs and MTAs may downgrade internationalized messages as 334 needed. The procedure for doing so is described in 335 [I-D.ietf-eai-downgrade]. 337 mailbox = name-addr / addr-spec / utf8-addr-spec 339 angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / 340 obs-angle-addr 342 utf8-addr-spec = utf8-local-part "@" utf8-domain 344 utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part 346 utf8-domain = utf8-dot-atom / domain-literal / obs-domain 348 alt-address = FWS "<" addr-spec ">" 350 Below list a few possible representation as example. 352 "DISPLAY_NAME" 353 ; traditional mailbox format 355 "DISPLAY_NAME" 356 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 357 ; message will bounce if UTF8SMTP extension is not supported 359 360 ; without DISPLAY_NAME and quoted string 361 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 362 ; message will bounce if UTF8SMTP extension is not supported 364 "DISPLAY_NAME" > 365 ; UTF8SMTP with ALT-ADDRESS parameter provided, 366 ; ALT-ADDRESS can be used if downgrade is necessary 368 4.5. Trace field syntax 370 "For" fields containing internationalized addresses are allowed, by 371 use of the new uFor syntax. UTF-8 information may be needed in 372 Received fields. Such information is therefore allowed to preserve 373 the integrity of those fields. The uFor syntax retains the original 374 UTF-8 email address between EAI-aware MTAs. Note that, should 375 downgrading be required, the uFor parameter is dropped per the 376 procedure specified in [I-D.ietf-eai-downgrade]. 378 The "Return-Path" header provides the email return address in the 379 mail delivery. Thus, it is augmented to carry UTF8 addresses (see 380 the revised syntax of in Section 4.4 of this document). 381 This will not break the rule of trace field integrity, because it is 382 added at the last MTA. 384 The on "Received:" syntax is augmented to allow UTF-8 385 email address on "For" clause. is augmented to include 386 UTF-8 email address. To allow UTF-8 email address also on syntax 387 corresponding of on original syntax, is 388 added to . 390 item-value =/ utf8-addr-spec 392 4.6. message/global 394 Internationalized messages must only be transmitted as authorized by 395 [I-D.ietf-eai-smtpext] or within a non-SMTP environment which 396 supports these messages. A message is a "message/global message", if 397 o it contains UTF-8 header values as specified in this document, or 398 o it contains UTF-8 values in the headers fields of body parts. 400 The type message/global is similar to message/rfc822, except that it 401 contains a message that can contain UTF-8 characters in the headers 402 of the message or body parts. If this type is sent to a 7-bit-only 403 system, it has to be encoded in [RFC2045]. (Note that a system 404 compliant with MIME that doesn't recognize message/global would treat 405 it as "application/octet-stream" as described in Section 5.2.4 of 406 [RFC2046].) 408 Alternatively, SMTP servers and other systems which transfer a 409 message/global body part MAY choose to down-convert it to a message/ 410 rfc822 body part using the rules described in 411 [I-D.ietf-eai-downgrade]. 413 Type name: message 415 Subtype name: global 417 Required parameters: none 419 Optional parameters: none 421 Encoding considerations: Any content-transfer-encoding is permitted. 422 The 8-bit or binary content-transfer-encodings are recommended 423 where permitted. 425 Security considerations: See Section 5 427 Interoperability considerations: The media type provides 428 functionality similar to the message/rfc822 content type for email 429 messages with international email headers. When there is a need 430 to embed or return such content in another message, there is 431 generally an option to use this media type and leave the content 432 unchanged or downconvert the content to message/rfc822. Both of 433 these choices will interoperate with the installed base, but with 434 different properties. Systems unaware of international headers 435 will typically treat a message/global body part as an unknown 436 attachment, while they will understand the structure of a message/ 437 rfc822. However, systems which understand message/global will 438 provide functionality superior to the result of a down-conversion 439 to message/rfc822. The most interoperable choice depends on the 440 deployed software. 442 Published specification: RFC XXXX 444 Applications that use this media type: SMTP servers and email 445 clients that support multipart/report generation or parsing. 446 Email clients which forward messages with international headers as 447 attachments. 449 Additional information: 451 Magic number(s): none 453 File extension(s): The extension ".u8msg" is suggested. 455 Macintosh file type code(s): A uniform type identifier (UTI) of 456 "public.utf8-email-message" is suggested. This conforms to 457 "public.message" and "public.composite-content" but does not 458 necessarily conform to "public.utf8-plain-text". 460 Person & email address to contact for further information: See the 461 Author's address section of this document. 463 Intended usage: COMMON 465 Restrictions on usage: This is a structured media type which embeds 466 other MIME media types. The 8-bit or binary content-transfer- 467 encoding MUST be used unless this media type is sent over a 7-bit 468 only transport. 470 Author: See Author's Address section of this document. 472 Change controller: IETF Standards Process 474 5. Security Considerations 476 If a user has a non-ASCII mailbox address and an ASCII mailbox 477 address, a digital certificate that identifies that user may have 478 both addresses in the identity. Having multiple email addresses as 479 identities in a single certificate is already supported in PKIX and 480 OpenPGP. 482 Because UTF-8 often requires several octets to encode a single 483 character, internationalized local parts may cause mail addresses to 484 become longer. As specified in [RFC2822], each line of characters 485 MUST be no more 998 octets, excluding the CRLF. 487 Because internationalized local parts may cause email addresses to be 488 longer, processes which parse, store, or handle email addresses or 489 local parts must take extra care not to overflow buffers, truncate 490 addresses, exceed storage allotments, or, when comparing, fail to use 491 the entire length. 493 In this specification, a user could provide an ASCII alternative 494 address for a non-ASCII address. However, it is possible these two 495 address go to different mailboxes, or even different persons. This 496 configuration may be based on a user's personal choice, or based on 497 administration policy. We recognize that if ASCII and non-ASCII 498 email is delivered to two different destinations, based on MTA 499 capability, this may violate the principle of least astonishment, but 500 this is not a "protocol problem". 502 The security impact of UTF-8 headers on email signature systems such 503 as DKIM, S/MIME and OpenPGP is discussed in RFC 4952 section 9. A 504 subsequent document [I-D.ietf-eai-downgrade] will cover the impact of 505 downgrading on these systems. 507 6. IANA considerations 509 IANA is asked to register the message/global MIME type using the 510 registration form contained in Section 4.4. 512 7. Acknowledgements 514 This document incorporates many ideas first described in Internet 515 Draft form by Paul Hoffman, although many details have changed from 516 that earlier work. 518 The author especially thank Jeff Yeh for their efforts and 519 contributions on editing previous versions. 521 Most of the content of this document is provided by John C Klensin. 522 Also some significant comments and suggestions were received from 523 Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris 524 Newman, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team 525 and were incorporated into the document. The editor is much great 526 thanks to their contribution sincerely. 528 8. Edit history 530 This section is used for tracking the update of this document. Will 531 be removed after finalize. 533 8.1. draft-ietf-eai-utf8header-12 535 1. Sentences modified 536 2. Update [RFC2045] into the Abstract 537 3. Update security mechanisms descriptions in Section 5 539 8.2. draft-ietf-eai-utf8header-11 541 1. Sentences modified 543 8.3. draft-ietf-eai-utf8header-10 545 1. Revise some paragraphs 546 2. Correct typos of ABNF 547 3. Note and of 2822bis 548 4. Fixed some idnits warnning 550 8.4. draft-ietf-eai-utf8header-09 552 1. Delete Section 5 (Addtional Issues) 553 2. Correct two typos of ABNF 554 3. Refine normalization issue to refer to [RFC5198] 555 4. Note and of 2822bis 556 5. Revise Section 6 558 8.5. draft-ietf-eai-utf8header-08 560 1. Sentences modified 562 8.6. draft-ietf-eai-utf8header-07 564 1. Modify subtype message/utf8smtp to message/global 565 2. Acknowledgements revise 567 8.7. draft-ietf-eai-utf8header-06 569 1. ABNF revise. 570 2. Sentences modified 571 3. Add paragraph in Section 5 572 4. Add paragraph in Section 1.2 573 5. Modify Section 4.6 575 8.8. draft-ietf-eai-utf8header-05 577 1. ABNF revise. 578 2. Remove original the section 4 (Pre-requirement) 579 3. Add UTF8SMTP message (Section 4.6) 581 8.9. draft-ietf-eai-utf8header-04 583 1. ABNF revise. 584 2. Modify uFor description in Section 4.5 586 8.10. draft-ietf-eai-utf8header-03 588 1. Editrial changes on terms and english. 589 2. ABNF revise. 590 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 591 "<" and ">". 592 4. Remove the "Header-Type" header. 593 5. Add uFor description in Section 4.5 594 6. Remove the content in IANA considerations since "Header-Type" is 595 removed. 597 8.11. draft-ietf-eai-utf8header-02 599 1. Editrial changes on terms and english. 600 2. Change the header name "UTF8SMTP" to "Header-Type", and ABNF 601 revise. 602 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 603 "[" and "]". 604 4. IANA considerations section rewrite. 606 8.12. draft-ietf-eai-utf8header-01 608 1. ABNF revise. 609 2. Terminology sync with overview document. 610 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 611 "{" and "}". 612 4. add IANA considerations to register the new 2822 header 613 "UTF8SMTP". 614 5. add Security considerations about relation of UTF8SMTP address to 615 ALT-ADDRESS. 617 8.13. draft-ietf-eai-utf8header-00 619 1. ABNF added. 620 2. Editrial changes. 621 3. Sent it as WG document. 623 8.14. draft-yeh-ima-utf8header-01 625 1. Section re-arranged. 626 2. Remove content are not below to this document. 628 9. References 630 9.1. Normative References 632 [I-D.ietf-eai-smtpext] 633 Yao, J. and W. MAO, "SMTP extension for internationalized 634 email address", draft-ietf-eai-smtpext-12 (work in 635 progress), April 2008. 637 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 638 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 639 RFC 1652, July 1994. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 645 April 2001. 647 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 648 April 2001. 650 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 651 10646", STD 63, RFC 3629, November 2003. 653 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 654 Internationalized Email", RFC 4952, July 2007. 656 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 657 Interchange", RFC 5198, March 2008. 659 9.2. Informative References 661 [I-D.ietf-eai-downgrade] 662 Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for 663 Email Address Internationalization", 664 draft-ietf-eai-downgrade-07 (work in progress), 665 March 2008. 667 [I-D.ietf-eai-imap-utf8] 668 Resnick, P. and C. Newman, "IMAP Support for UTF-8", 669 draft-ietf-eai-imap-utf8-03 (work in progress), 670 April 2008. 672 [I-D.ietf-eai-pop] 673 Newman, C. and R. Gellens, "POP3 Support for UTF-8", 674 draft-ietf-eai-pop-03 (work in progress), February 2008. 676 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 677 Extensions (MIME) Part One: Format of Internet Message 678 Bodies", RFC 2045, November 1996. 680 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 681 Extensions (MIME) Part Two: Media Types", RFC 2046, 682 November 1996. 684 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 685 Part Three: Message Header Extensions for Non-ASCII Text", 686 RFC 2047, November 1996. 688 Author's Address 690 Abel Yang (editor) 691 TWNIC 692 4F-2, No. 9, Sec 2, Roosvelt Rd. 693 Taipei, 100 694 Taiwan 696 Phone: +886 2 23411313 ext 505 697 Email: abelyang@twnic.net.tw 699 Full Copyright Statement 701 Copyright (C) The IETF Trust (2008). 703 This document is subject to the rights, licenses and restrictions 704 contained in BCP 78, and except as set forth therein, the authors 705 retain all their rights. 707 This document and the information contained herein are provided on an 708 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 709 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 710 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 711 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 712 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 713 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 715 Intellectual Property 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be 724 found in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this 730 specification can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at 737 ietf-ipr@ietf.org.