idnits 2.17.1 draft-ietf-eai-utf8headers-09.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 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 719. 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 05, 2008) is 5919 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 338, but not defined == Unused Reference: 'ASCII' is defined on line 606, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-11 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-05 == Outdated reference: A later version (-09) exists of draft-klensin-net-utf8-07 -- Obsolete informational reference (is this intentional?): RFC 1652 (Obsoleted by RFC 6152) -- Obsolete informational reference (is this intentional?): RFC 4952 (Obsoleted by RFC 6530) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 10 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 Expires: August 8, 2008 February 05, 2008 5 Internationalized Email Headers 6 draft-ietf-eai-utf8headers-09.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2008. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2008). 37 Abstract 39 Full internationalization of electronic mail requires not only the 40 capability to transmit non-ASCII content, to encode selected 41 information in specific header fields, and to use non-ASCII 42 characters in envelope addresses. It also requires being able to 43 express those addresses and information based on them in mail header 44 fields. This document specifies an experimental variant of Internet 45 mail that permits the use of Unicode encoded in UTF-8, rather than 46 ASCII, as the base form for Internet email header field bodies. This 47 form is permitted in transmission only if authorized by an SMTP 48 extension, as specified in an associated specification. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 54 1.2. Relation to other standards . . . . . . . . . . . . . . . 3 55 2. Background and History . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 58 4.1. UTF8 Syntax and Normalization . . . . . . . . . . . . . . 5 59 4.2. Changes on MIME headers . . . . . . . . . . . . . . . . . 6 60 4.3. Syntax extensions to RFC 2822 . . . . . . . . . . . . . . 6 61 4.4. Change on addr-spec syntax . . . . . . . . . . . . . . . . 8 62 4.5. Trace field syntax . . . . . . . . . . . . . . . . . . . . 9 63 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 67 8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. draft-ietf-eai-utf8header-09 . . . . . . . . . . . . . . . 12 69 8.2. draft-ietf-eai-utf8header-08 . . . . . . . . . . . . . . . 12 70 8.3. draft-ietf-eai-utf8header-07 . . . . . . . . . . . . . . . 12 71 8.4. draft-ietf-eai-utf8header-06 . . . . . . . . . . . . . . . 12 72 8.5. draft-ietf-eai-utf8header-05 . . . . . . . . . . . . . . . 13 73 8.6. draft-ietf-eai-utf8header-04 . . . . . . . . . . . . . . . 13 74 8.7. draft-ietf-eai-utf8header-03 . . . . . . . . . . . . . . . 13 75 8.8. draft-ietf-eai-utf8header-02 . . . . . . . . . . . . . . . 13 76 8.9. draft-ietf-eai-utf8header-01 . . . . . . . . . . . . . . . 13 77 8.10. draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 13 78 8.11. draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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 express those addresses, and information related 95 to and based on them, in mail header fields, defined in this 96 document. And, finally, 97 o The capability to use international characters in envelope 98 addresses, discussed in [RFC4952] and specified in 99 [EAI-SMTP-extension]. 101 This document specifies an experimental variant of Internet mail that 102 permits the use of Unicode encoded in UTF-8 [RFC3629], rather than 103 ASCII, as the base form for Internet email header fields. This form 104 is permitted in transmission, if authorized by the SMTP extension 105 specified in [EAI-SMTP-extension] or by other transport mechanisms 106 capable of processing it. 108 1.2. Relation to other standards 110 This document updates section 6.4 of RFC 2045. 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 [RFC2822] and MIME, and the fact that an 117 experimental specification updates a standards-track spec means that 118 people who participate in the experiment have to consider those 119 standards updated. 121 Allowing of use a content-transfer-encoding on subtypes of messages 122 is not limited to transmissions, which are authorized by the SMTP 123 extension specified in [EAI-SMTP-extension]. Message/global permits 124 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. 133 These users are also likely to use non-ASCII text in their common 134 names and subjects of email messages, both in what they send and what 135 they receive. This protocol specifies UTF-8 as the encoding to 136 represent email header field bodies. 138 The traditional format of email messages [RFC2822] allows only ASCII 139 characters in the header fields of messages. This prevents users 140 from having email addresses that contain non-ASCII characters. It 141 further forces non-ASCII text in common names, comments, and in free 142 text (such as in the Subject: field) to be encoded (as required by 143 MIME format [RFC2047]). This specification describes a change to the 144 email message format that is related to the SMTP message transport 145 change described in the associated document [RFC4952] and 146 [EAI-SMTP-extension], and that allows non-ASCII characters in most 147 email header fields. These changes affect SMTP clients, SMTP 148 servers, mail user agents (MUAs), list expanders, gateways to other 149 media, and all other processes that parse or handle email messages. 151 As specified in [EAI-SMTP-extension], an SMTP protocol extension 152 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 153 header fields to systems that cannot handle such messages. 155 Use of this SMTP extension helps prevents 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 transfering 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 related documents. 164 The objective for this protocol is to allow UTF-8 in email header 165 fields. Issues about how to handle messages that contain UTF-8 166 header fields but are proposed to be delivered to systems that have 167 not been upgraded to support this capability are discussed elsewhere, 168 particularly in [EAI-downgrading]. 170 3. Terminology 172 A plain ASCII string is also a valid UTF-8 string, see [RFC3629]. In 173 this document, ordinary ASCII characters are UTF-8 characters if they 174 are in headers which contain s. 176 Unless otherwise noted, all terms used here are defined in [RFC2821] 177 ,[RFC2822] , [RFC4952], or [EAI-SMTP-extension]. 179 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 180 and "MAY" in this document are to be interpreted as described in 181 [RFC2119]. 183 This document is discussed on the ima mailing list. See 184 https://www1.ietf.org/mailman/listinfo/ima for information about 185 subscribing. The list's archive is at 186 http://www1.ietf.org/mail-archive/web/ima/index.html. 188 4. Changes on Message Header Fields 190 SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP 191 extension is advertised by the SMTP server or as permitted by other 192 transport mechanisms. 194 This protocol does NOT change the definition of header field names. 195 That is, only the bodies of header fields are allowed to have UTF-8 196 characters; the rules in [RFC2822] for header field names are not 197 changed. 199 To permit UTF-8 characters in field values, the header definition in 200 [RFC2822] must be extended to support new format. The following ABNF 201 is defined to substitute those definition in [RFC2822]. 203 Those syntax rules not referred to this section remain as the 204 original definition in [RFC2822]. 206 4.1. UTF8 Syntax and Normalization 208 UTF-8 characters can be defined in terms of octets using the 209 following ABNF, taken from [RFC3629]: 211 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 213 UTF8-2 = %xC2-DF UTF8-tail 215 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 216 %xE1-EC 2(UTF8-tail) / 217 %xED %x80-9F UTF8-tail / 218 %xEE-EF 2(UTF8-tail) 220 UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / 221 %xF1-F7 3(UTF8-tail) 223 UTF8-tail = %x80-BF 225 These are taken from [RFC3629], but kept in this document for reasons 226 of convenience. 228 This specification does not require a specific normalization of the 229 Unicode strings, but recommends that good practices for normalization 230 be followed. See [Net-UTF8] for a discussion on recommended 231 practices for normalizing text before sending. 233 4.2. Changes on MIME headers 235 This specification updates section 6.4 of [RFC2045]. [RFC2045] 236 prohibits applying a content-transfer-encoding to all subtypes of 237 message/. This specification relaxes the rule, allowing newly 238 defined MIME types to permit content-transfer-encoding, and permits 239 content-transfer-encoding for message/global (see Section 4.6). 241 Background: Normally, transfer of message/global will be done in 242 8-bit-clean channels, and body parts will have "identity" encodings, 243 that is, no decoding is necessary. In the case where a message 244 containing a message/global is downgraded from 8-bit to 7-bit as 245 described in [RFC1652]., an encoding may be applied to the message; 246 if the message travels multiple times between a 7-bit environment and 247 an environment implementing UTF8SMTP, multiple levels of encoding may 248 occur. This is expected to be rarely seen in practice, and the 249 potential complexity of other ways of dealing with the issue are 250 thought to be larger than the complexity of allowing nested encodings 251 where necessary. 253 4.3. Syntax extensions to RFC 2822 255 The following rules are intended to extend the corresponding rules in 256 [RFC2822] to allow UTF8 characters. 258 ctext =/ UTF8-xtra-char 260 utext =/ UTF8-xtra-char 262 comment = "(" *([FWS] utf8-ccontent) [FWS] ")" 264 word = utf8-atom / utf8-quoted-string 266 This means that all the [RFC2822] constructs that build upon these 267 will permit UTF-8 characters, including comments and quoted strings. 268 Besides, in order to allow UTF8 characters in we have to 269 change the syntax of . However, it would also lead 270 to allow UTF8 characters, which is not allowed due to 271 the limitation described in Section 4.5. So is added to 272 meet this requirement. 274 utf8-text = %d1-9 / ; all UTF-8 characters except 275 %d11-12 / ; US-ASCII NUL, CR and LF 276 %d14-127 / 277 UTF8-xtra-char 279 utf8-quoted-pair = ("\" utf8-text) / obs-qp 281 utf8-qcontent = utf8-text / utf8-quoted-pair 283 utf8-quoted-string = [CFWS] 284 DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE 285 [CFWS] 287 utf8-ccontent = ctext / utf8-quoted-pair / comment 288 utf8-text= text / UTF8-xtra-char 289 utf8-atext = ALPHA / DIGIT / 290 "!" / "#" / ; Any character except 291 "$" / "%" / ; controls, SP, and specials. 292 "&" / "'" / ; Used for atoms 293 "*" / "+" / 294 "-" / "/" / 295 "=" / "?" / 296 "^" / "_" / 297 "`" / "{" / 298 "|" / "}" / 299 "~" / 300 UTF8-xtra-char 302 utf8-atom = [CFWS] 1*utf8-atext [CFWS] 304 utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] 306 utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) 308 qcontent = utf8-qcontent 310 [NOTE IN DRAFT: the references to 2822bis. if 2822bis is 311 finished, we will clean this mess up.] 313 To able to use UTF-8 on Content-Description header field on 314 [RFC2045], following syntax is used 316 description = "Content-Description:" unstructured CRLF 318 syntax is extended on next chapter to allow UTF-8 characters 319 on 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 affects 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 as well as an additional, optional all-ascii alternate address. Note 332 that MSAs and MTAs may downgrade internationalized messages as 333 needed. The procedure for doing so in described in 334 [EAI-downgrading]. 336 mailbox = name-addr / addr-spec / utf8-addr-spec 338 angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] / 339 obs-angle-addr 341 utf8-addr-spec = utf8-local-part "@" utf8-domain 343 utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part 345 utf8-domain = utf8-dot-atom / domain-literal / obs-domain 347 alt-address = 1*FWS "<" addr-spec ">" 349 Below list a few possible representation as example. 351 "DISPLAY_NAME" 352 ; traditional mailbox format 354 "DISPLAY_NAME" 355 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 356 ; message will bounce if UTF8SMTP extension is not supported 358 359 ; without DISPLAY_NAME and quoted string 360 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 361 ; message will bounce if UTF8SMTP extension is not supported 363 "DISPLAY_NAME" > 364 ; UTF8SMTP with ALT-ADDRESS parameter provided, 365 ; ALT-ADDRESS can be used if downgrade is necessary 367 4.5. Trace field syntax 369 "For" fields containing internationalized addresses are allowed, by 370 use of the new uFor syntax. UTF-8 information in needed in Received 371 fields and such information is therefore allowed, to preserve the 372 integrity of those fields. The uFor syntax retains the original 373 UTF-8 email address between EAI-aware MTAs. Note that, should 374 downgrading be required, the uFor parameter is dropped per the 375 procedure specified in [EAI-downgrading]. 377 The "Return-Path" header provides the email return address in the 378 mail delivery. Thus, it MUST able to carry UTF8 addresses (see the 379 revised syntax of in Section 4.4 of this document). 380 This will not break the rule of trace fied integrity, because it is 381 added at the last MTA. 383 on "Received:" syntax is augmented to allow UTF-8 email 384 address on "For" clause. is augmented to include UTF-8 385 email address on previous chapter. To allow UTF-8 email address also 386 on syntax corresponding of on original syntax, is added to . 389 item-value =/ utf8-addr-spec 391 4.6. message/global 393 Internationalized messages must only be transmitted as authorized by 394 [EAI-SMTP-extension] or within a non-SMTP environment which supports 395 these messages. A message is a "message/global message", if 396 o it contains UTF-8 header values as specified in this document, or 397 o it contains UTF-8 values in the headers fields of body parts. 399 The type message/global is similar to message/rfc822, except that it 400 contains a message that can contain UTF-8 characters in the headers 401 of the message or body parts. headers. If this type is sent to a 402 7-bit-only system, it has to be encoded in [RFC2045]. Note that a 403 system compliant with MIME that doesn't recognize message/global 404 would treat it as "application/octet-stream" as described in Section 405 5.2.4 of [RFC2046]. 407 Alternatively, SMTP servers and other systems which transfer a 408 message/global body part MAY choose to down-convert it to a message/ 409 rfc822 body part using the rules described in [EAI-downgrading]. 411 Type name: message 413 Subtype name: global 415 Required parameters: none 417 Optional parameters: none 419 Encoding considerations: Any content-transfer-encoding is permitted. 420 The 8-bit or binary content-transfer-encodings are recommended 421 where permitted. 423 Security considerations: See Section 5 425 Interoperability considerations: The media type provides 426 functionality similar to the message/rfc822 content type for email 427 messages with international email headers. When there is a need 428 to embed or return such content in another message, there is 429 generally an option to use this media type and leave the content 430 unchanged or downconvert the content to message/rfc822. Both of 431 these choices will interoperate with the installed base, but with 432 different properties. Systems unaware of international headers 433 will typically treat a message/global body part as an unknown 434 attachment, while they will understand the structure of a message/ 435 rfc822. However, systems which understand message/global will 436 provide functionality superior to the result of a down-conversion 437 to message/rfc822. The most interoperable choice depends on the 438 deployed software. 440 Published specification: RFC XXXX 442 Applications that use this media type: SMTP servers and email 443 clients that support multipart/report generation or parsing. 444 Email clients which forward messages with international headers as 445 attachments. 447 Additional information: 449 Magic number(s): none 451 File extension(s): The extension ".u8msg" is suggested. 453 Macintosh file type code(s): A uniform type identifier (UTI) of 454 "public.utf8-email-message" is suggested. This conforms to 455 "public.message" and "public.composite-content" but does not 456 necessarily conform to "public.utf8-plain-text". 458 Person & email address to contact for further information: See the 459 Author's address section of this document. 461 Intended usage: COMMON 463 Restrictions on usage: This is a structured media type which embeds 464 other MIME media types. The 8-bit or binary content-transfer- 465 encoding MUST be used unless this media type is sent over a 7-bit 466 only transport. 468 Author: See Author's Address section of this document. 470 Change controller: IETF Standards Process 472 5. Security Considerations 474 If a user has a non-ASCII mailbox address and an ASCII mailbox 475 address, a digital certificate that identifies that user may have 476 both addresses in the identity. Having multiple email addresses as 477 identities in a single certificate is already supported in PKIX and 478 OpenPGP. 480 Because UTF-8 often requires several octets to encode a single 481 character, internationalized local parts may cause mail addresses to 482 become longer. As specified in [RFC2822], each line of characters 483 MUST be no more 998 octets, excluding the CRLF. 485 Because internationalized local parts may cause email addresses to be 486 longer, processes which parse, store, or handle email addresses or 487 local parts must take extra care not to overflow buffers, truncate 488 addresses, exceed storage allotments, or, when comparing, fail to use 489 the entire length. 491 In this specification, a user could provide an ASCII alternative 492 address for a non-ASCII address. However, it is possible these two 493 address go to different mailboxes, or even different persons. This 494 might not be a protocol problem, but instead be the user's personal 495 choice or administration policy or even be a deliberate attempt to 496 deceive or cause confusion. 498 6. IANA considerations 500 IANA is requested to register the MIME type message/global, using the 501 registration data in section Section 4.6. 503 7. Acknowledgements 505 This document was created by incorporating a good deal of material 506 from an old Internet Draft by Paul Hoffman [Hoffman-utf8-headers]. 507 While many of the concepts and details have changed, the 508 contributions from that draft are greatly appreciated. 510 The author especially thank Jeff Yeh for their efforts and 511 contributions on editing previous versions. 513 Most of the content of this document is provided by John C Klensin. 514 Also some significant comments and suggestions were received from 515 Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris 516 Newman, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team 517 and were incorporated into the document. The editor is much great 518 thanks to their contribution sincerely. 520 8. Edit history 522 This section is used for tracking the update of this document. Will 523 be removed after finalize. 525 8.1. draft-ietf-eai-utf8header-09 527 1. Delete Section 5 (Addtional Issues) 528 2. Correct two typos of ABNF 529 3. Refine normalization issue to refer to [Net-UTF8] 530 4. Note of 2822bis 531 5. Revise Section 6 533 8.2. draft-ietf-eai-utf8header-08 535 1. Sentences modified 537 8.3. draft-ietf-eai-utf8header-07 539 1. Modify subtype message/utf8smtp to message/global 540 2. Acknowledgements revise 542 8.4. draft-ietf-eai-utf8header-06 544 1. ABNF revise. 545 2. Sentences modified 546 3. Add paragraph in Section 5 547 4. Add paragraph in Section 1.2 548 5. Modify Section 4.6 550 8.5. draft-ietf-eai-utf8header-05 552 1. ABNF revise. 553 2. Remove original the section 4 (Pre-requirement) 554 3. Add UTF8SMTP message (Section 4.6) 556 8.6. draft-ietf-eai-utf8header-04 558 1. ABNF revise. 559 2. Modify uFor description in Section 4.5 561 8.7. draft-ietf-eai-utf8header-03 563 1. Editrial changes on terms and english. 564 2. ABNF revise. 565 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 566 "<" and ">". 567 4. Remove the "Header-Type" header. 568 5. Add uFor description in Section 4.5 569 6. Remove the content in IANA considerations since "Header-Type" is 570 removed. 572 8.8. draft-ietf-eai-utf8header-02 574 1. Editrial changes on terms and english. 575 2. Change the header name "UTF8SMTP" to "Header-Type", and ABNF 576 revise. 577 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 578 "[" and "]". 579 4. IANA considerations section rewrite. 581 8.9. draft-ietf-eai-utf8header-01 583 1. ABNF revise. 584 2. Terminology sync with overview document. 585 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 586 "{" and "}". 587 4. add IANA considerations to register the new 2822 header 588 "UTF8SMTP". 589 5. add Security considerations about relation of UTF8SMTP address to 590 ALT-ADDRESS. 592 8.10. draft-ietf-eai-utf8header-00 593 1. ABNF added. 594 2. Editrial changes. 595 3. Sent it as WG document. 597 8.11. draft-yeh-ima-utf8header-01 599 1. Section re-arranged. 600 2. Remove content are not below to this document. 602 9. References 604 9.1. Normative References 606 [ASCII] American National Standards Institute (formerly United 607 States of America Standards Institute), "USA Code for 608 Information Interchange", ANSI X3.4-1968, 1968. 610 ANSI X3.4-1968 has been replaced by newer versions with 611 slight modifications, but the 1968 version remains 612 definitive for the Internet. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 618 April 2001. 620 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 621 April 2001. 623 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 624 10646", STD 63, RFC 3629, November 2003. 626 9.2. Informative References 628 [EAI-SMTP-extension] 629 Yao, J., Ed. and Wei. Mao, "SMTP extension for 630 internationalized email address", 631 draft-ietf-eai-smtpext-11.txt (work in progress), 632 January 2008. 634 [EAI-downgrading] 635 YONEYA, Yoshiro., Ed. and Kazunori. Fujiwara, Ed., 636 "Downgrading mechanism for Internationalized eMail Address 637 (IMA)", draft-ietf-eai-downgrade-05.txt (work in 638 progress), November 2007. 640 [Hoffman-utf8-headers] 641 Hoffman, P., "SMTP Service Extensions or Transmission of 642 Headers in UTF-8 Encoding", 643 draft-hoffman-utf8headers-00.txt (work in progress), 644 December 2003. 646 [Net-UTF8] 647 Klensin, J. and A. Padlipsky, "Unicode Format for Network 648 Interchange", draft-klensin-net-utf8-07.txt (work in 649 progress), January 2008. 651 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 652 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 653 RFC 1652, July 1994. 655 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 656 Extensions (MIME) Part One: Format of Internet Message 657 Bodies", RFC 2045, November 1996. 659 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 660 Extensions (MIME) Part Two: Media Types", RFC 2046, 661 November 1996. 663 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 664 Part Three: Message Header Extensions for Non-ASCII Text", 665 RFC 2047, November 1996. 667 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 668 Internationalized Email", RFC 4952, July 2007. 670 Author's Address 672 Abel Yang (editor) 673 TWNIC 674 4F-2, No. 9, Sec 2, Roosvelt Rd. 675 Taipei, 100 676 Taiwan 678 Phone: +886 2 23411313 ext 505 679 Email: abelyang@twnic.net.tw 681 Full Copyright Statement 683 Copyright (C) The IETF Trust (2008). 685 This document is subject to the rights, licenses and restrictions 686 contained in BCP 78, and except as set forth therein, the authors 687 retain all their rights. 689 This document and the information contained herein are provided on an 690 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 691 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 692 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 693 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 694 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 697 Intellectual Property 699 The IETF takes no position regarding the validity or scope of any 700 Intellectual Property Rights or other rights that might be claimed to 701 pertain to the implementation or use of the technology described in 702 this document or the extent to which any license under such rights 703 might or might not be available; nor does it represent that it has 704 made any independent effort to identify any such rights. Information 705 on the procedures with respect to rights in RFC documents can be 706 found in BCP 78 and BCP 79. 708 Copies of IPR disclosures made to the IETF Secretariat and any 709 assurances of licenses to be made available, or the result of an 710 attempt made to obtain a general license or permission for the use of 711 such proprietary rights by implementers or users of this 712 specification can be obtained from the IETF on-line IPR repository at 713 http://www.ietf.org/ipr. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights that may cover technology that may be required to implement 718 this standard. Please address the information to the IETF at 719 ietf-ipr@ietf.org. 721 Acknowledgment 723 Funding for the RFC Editor function is provided by the IETF 724 Administrative Support Activity (IASA).