idnits 2.17.1 draft-ietf-eai-utf8headers-06.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 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. 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 (July 05, 2007) is 6139 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: 'AUTHOR NOTE' is mentioned on line 124, but not defined == Missing Reference: 'CFWS' is mentioned on line 341, but not defined == Unused Reference: 'ASCII' is defined on line 611, 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-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-smtpext (ref. 'EAI-SMTP-extension') ** Downref: Normative reference to an Informational draft: draft-ietf-eai-framework (ref. 'EAI-framework') == 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') ** 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-03 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 9 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: January 6, 2008 July 05, 2007 5 Internationalized Email Headers 6 draft-ietf-eai-utf8headers-06.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 January 6, 2008. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . 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/utf8smtp . . . . . . . . . . . . . . . . . . . . . 9 64 5. Additional issues . . . . . . . . . . . . . . . . . . . . . . 11 65 5.1. Mailing list header fields . . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9.1. draft-ietf-eai-utf8header-06 . . . . . . . . . . . . . . . 13 71 9.2. draft-ietf-eai-utf8header-05 . . . . . . . . . . . . . . . 13 72 9.3. draft-ietf-eai-utf8header-04 . . . . . . . . . . . . . . . 13 73 9.4. draft-ietf-eai-utf8header-03 . . . . . . . . . . . . . . . 13 74 9.5. draft-ietf-eai-utf8header-02 . . . . . . . . . . . . . . . 13 75 9.6. draft-ietf-eai-utf8header-01 . . . . . . . . . . . . . . . 14 76 9.7. draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 14 77 9.8. draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Intellectual Property and Copyright Statements . . . . . . . . . . 17 84 1. Introduction 86 1.1. Role of this specification 88 Full internationalization of electronic mail requires several 89 capabilities: 91 o The capability to transmit non-ASCII content, provided for as part 92 of the basic MIME specification [RFC2045], [RFC2046]. 93 o The capability to express those addresses, and information related 94 to and based on them, in mail header fields, defined in this 95 document. And, finally, 96 o The capability to use international characters in envelope 97 addresses, discussed in [EAI-framework] and specified in 98 [EAI-SMTP-extension]. 99 o 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 update [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/utf8smtp 124 permits use of a content-transfer-encoding. ([AUTHOR NOTE] The 125 message/utf8smtp is a placeholder for whatever the WG decides to call 126 it) 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. 134 These users are also likely to use non-ASCII text in their common 135 names and subjects of email messages, both in what they send and what 136 they receive. This protocol specifies UTF-8 as the encoding to 137 represent email header field bodies. 139 The traditional format of email messages [RFC2822] allows only ASCII 140 characters in the header fields of messages. This prevents users 141 from having email addresses that contain non-ASCII characters. It 142 further forces non-ASCII text in common names, comments, and in free 143 text (such as in the Subject: field) to be encoded (as required by 144 MIME format [RFC2047]). This specification describes a change to the 145 email message format that is related to the SMTP message transport 146 change described in the associated document [EAI-framework] and 147 [EAI-SMTP-extension], and that allows non-ASCII characters in most 148 email header fields. These changes affect SMTP clients, SMTP 149 servers, mail user agents (MUAs), list expanders, gateways to other 150 media, and all other processes that parse or handle email messages. 152 As specified in [EAI-SMTP-extension], an SMTP protocol extension 153 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 154 header fields to systems that cannot handle such messages. 156 Use of this SMTP extension helps prevents the introduction of such 157 messages into message stores that might misinterpret, improperly 158 display, or mangle such messages. It should be noted that using an 159 ESMTP extension does not prevent transfering email messages with 160 UTF-8 header fields to other systems that use the email format for 161 messages and that may not be upgraded, such as unextended POP and 162 IMAP servers. Changes to these protocols to handle UTF-8 header 163 fields are addressed in related documents. 165 The objective for this protocol is to allow UTF-8 in email header 166 fields. Issues about how to handle messages that contain UTF-8 167 header fields but are proposed to be delivered to systems that have 168 not been upgraded to support this capability are discussed elsewhere, 169 particularly in [EAI-downgrading]. 171 3. Terminology 173 A plain ASCII string is also a valid UTF-8 string, see [RFC3629]. In 174 this document, ordinary ASCII characters are UTF-8 characters if they 175 are in headers which contain s. 177 Unless otherwise noted, all terms used here are defined in [RFC2821] 178 or [RFC2822] or in [EAI-framework]. 180 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 181 and "MAY" in this document are to be interpreted as described in 182 [RFC2119]. 184 This document is discussed on the ima mailing list. See 185 https://www1.ietf.org/mailman/listinfo/ima for information about 186 subscribing. The list's archive is at 187 http://www1.ietf.org/mail-archive/web/ima/index.html. 189 4. Changes on Message Header Fields 191 SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP 192 extension is advertised by the SMTP server or as permitted by other 193 transport mechanisms. 195 This protocol does NOT change the definition of header field names. 196 That is, only the bodies of header fields are allowed to have UTF-8 197 characters; the rules in [RFC2822] for header field names are not 198 changed. 200 To permit UTF-8 characters in field values, the header definition in 201 [RFC2822] must be extended to support new format. The following ABNF 202 is defined to substitute those definition in [RFC2822]. 204 Those syntax rules not referred to this section remain as the 205 original definition in [RFC2822]. 207 4.1. UTF8 Syntax 209 UTF-8 characters can be defined in terms of octets using the 210 following ABNF, taken from [RFC3629]:" 212 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 214 UTF8-2 = %xC2-DF UTF8-tail 216 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 217 %xE1-EC 2(UTF8-tail) / 218 %xED %x80-9F UTF8-tail / 219 %xEE-EF 2(UTF8-tail) 221 UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / 222 %xF1-F7 3(UTF8-tail) 224 UTF8-tail = %x80-BF 225 These are taken from [RFC3629], but kept in this document for reasons 226 of convenience. 227 [Note in draft: Whether normalizing is needed or not will be place in 228 here.] 230 4.2. Changes on MIME headers 232 This specification updates section 6.4 of RFC 2045. RFC 2045 233 prohibits applying a content-transfer-encoding to all subtypes of 234 message/. This specification relaxes the rule, permitting content- 235 transfer-encoding for message/utf8smtp only (see Section 4.6). 236 Normally, transfer of message/utf8smtp will be done in 8-bit-clean 237 channels, and body parts will have 8-bit encodings. The additional 238 complexity of a content-transfer-encoding on "message" is therefore 239 acceptable. This specification does not prohibit other content- 240 transfer-encodings on nested body parts, so double encoding might 241 happen, but is expected to be rarely seen in practice. 243 To be able to use UTF-8 characters in MIME header field paramerer 244 values, the syntax of , as defined in [RFC2045], is extended 245 as 247 value =/ utf8-quoted-string 249 Because of MIME's structure, Content-Type and other header fields may 250 be found both amongst the top-level fields of a message and also 251 within its body parts. 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 the limitation 271 described in Section 4.5. So is added to meet this 272 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-qtext / 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-qtext= qtext / UTF8-xtra-char 289 qtext = NO-WS-CTL / ; all of except 290 %d33 / ; The rest of the US-ASCII 291 %d35-91 / ; characters not including "\" 292 %d93-126 / ; or the quote character 294 utf8-atext = ALPHA / DIGIT / 295 "!" / "#" / ; Any character except 296 "$" / "%" / ; controls, SP, and specials. 297 "&" / "'" / ; Used for atoms 298 "*" / "+" / 299 "-" / "/" / 300 "=" / "?" / 301 "^" / "_" / 302 "`" / "{" / 303 "|" / "}" / 304 "~" / 305 UTF8-xtra-char 307 utf8-atom = [CFWS] 1*utf8-atext [CFWS] 309 utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] 311 utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) 313 qcontent = utf8-qcontent 315 To able to use UTF-8 on Content-Description header field on 316 [RFC2045], following syntax is used 317 description = "Content-Description:" unstructured CRLF 319 syntax is extended on next chapter to allow UTF-8 characters 320 on header fields. 322 [NOTE IN DRAFT: If any header needs to be restricted to disallow 323 this, please raise the issue on the mailing list.] 324 Note, however, this does not remove any constraint on the character 325 set of protocol elements; for instance, all the allowed values for 326 timezone in the Date: headers are still expressed in ASCII. And 327 also, none of this revised syntax affects what is allowed in a 328 , which will still remain in pure ASCII. 330 4.4. Change on addr-spec syntax 332 Internationalized email addresses are represented in UTF-8. Thus, 333 all header fields containing es are updated to permit UTF-8 334 as well as an additional, optional all-ascii alternate address. Note 335 that MSAs and MTAs may downgrade internationalized messages as 336 needed. The procedure for doing so in described in 337 [EAI-downgrading]. 339 mailbox = name-addr / addr-spec / utf8-addr-spec 341 angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">" [CFWS] \ 342 / obs-angle-addr 344 utf8-addr-spec = utf8-local-part "@" utf8-domain 346 utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part 348 utf8-domain = utf8-dot-atom / domain-literal / obs-domain 350 alt-address = 1*FWS "<" addr-spec ">" 352 Below list a few possible representation as example. 354 "DISPLAY_NAME" 355 ; traditional mailbox format 357 "DISPLAY_NAME" 358 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 359 ; message will bounce if UTF8SMTP extension is not supported 361 362 ; without DISPLAY_NAME and quoted string 363 ; UTF8SMTP but no ALT-ADDRESS parameter provided, 364 ; message will bounce if UTF8SMTP extension is not supported 366 "DISPLAY_NAME" > 367 ; UTF8SMTP with ALT-ADDRESS parameter provided, 368 ; ALT-ADDRESS can be used if downgrade is necessary 370 4.5. Trace field syntax 372 "For" fields containing internationalized addresses are allowed, by 373 use of the new uFor syntax. UTF-8 information in needed in Received 374 fields and such information is therefore allowed, to preserve the 375 integrity of those fields. The uFor syntax retains the original 376 UTF-8 email address between EAI-aware MTAs. Note that, should 377 downgrading be required, the uFor parameter is dropped per the 378 procedure specified in [EAI-downgrading]. 380 The "Return-Path" header provides the email return address in the 381 mail delivery. Thus, it MUST able to carry UTF8 addresses (see the 382 revised syntax of in Section 4.4 of this document). 383 This will not break the rule of trace fied integrity, because it is 384 added at the last MTA. 386 on "Received:" syntax is augmented to allow UTF-8 email 387 address on "For" clause. is augmented to include UTF-8 388 email address on previous chapter. To allow UTF-8 email address also 389 on syntax corresponding of on original syntax, is added to . 392 item-value =/ utf8-addr-spec 394 4.6. message/utf8smtp 396 Internationalized messages, also called UTF8SMTP messages, must only 397 be transmitted as authorized by [EAI-SMTP-extension] or within a non- 398 SMTP environment which supports these messages. A message is a 399 "UTF8SMTP message", if 400 o it contains UTF-8 header values as specified in this document, or 401 o it contains UTF-8 values in the headers fields of body parts. 403 The second type, used for content return, is message/utf8smtp which 404 is similar to message/rfc822, except it contains a message with UTF-8 405 headers. This type has profound implications on the email 406 infrastructure. First, [RFC3501] servers MUST NOT descend a message/ 407 utf8smtp when generating the message BODYSTRUCTURE, it is likely a 408 new variant on BODYSTRUCTURE will be necessary that does descend 409 message/utf8smtp body parts. Second, if this type is sent to a 410 7-bit-only system, it could be encoded in [RFC2045]. (Note that a 411 system compliant with MIME that doesn't recognize message/utf8smtp 412 would treat it as "application/octet-stream" as described in Section 413 5.2.4 of [RFC2046].) Alternatively, SMTP servers and other systems 414 which transfer a message/utf8smtp body part MAY choose to down- 415 convert it to a message/rfc822 body part using the rules described in 416 [EAI-downgrading]. 418 Type name: message 420 Subtype name: utf8smtp 422 Required parameters: none 424 Optional parameters: none 426 Encoding considerations: The 8-bit or binary content-transfer- 427 encoding MUST be used unless this media type is sent over a 7-bit 428 only transport. 430 Security considerations: See Section 6 432 Interoperability considerations: The media type provides 433 functionality similar to the message/rfc822 content type for email 434 messages with international email headers. When there is a need 435 to embed or return such content in another message, there is 436 generally an option to use this media type and leave the content 437 unchanged or downconvert the content to message/rfc822. Both of 438 these choices will interoperate with the installed base, but with 439 different properties. Systems unaware of international headers 440 will typically treat a message/utf8smtp body part as an unknown 441 attachment, while they will understand the structure of a message/ 442 rfc822. However, systems which understand message/utf8smtp will 443 provide functionality superior to the result of a down-conversion 444 to message/rfc822. The most interoperable choice depends on the 445 deployed software. 447 Published specification: RFC XXXX 449 Applications that use this media type: SMTP servers and email 450 clients that support multipart/report generation or parsing. 451 Email clients which forward messages with international headers as 452 attachments. 454 Additional information: 456 Magic number(s): none 458 File extension(s): The extension ".u8msg" is suggested. 460 Macintosh file type code(s): A uniform type identifier (UTI) of 461 "public.utf8-email-message" is suggested. This conforms to 462 "public.message" and "public.composite-content" but does not 463 necessarily conform to "public.utf8-plain-text". 465 Person & email address to contact for further information: See the 466 Author's address section of this document. 468 Intended usage: COMMON 470 Restrictions on usage: This is a structured media type which embeds 471 other MIME media types. The 8-bit or binary content-transfer- 472 encoding MUST be used unless this media type is sent over a 7-bit 473 only transport. 475 Author: See Author's Address section of this document. 477 Change controller: IETF Standards Process 479 5. Additional issues 481 This section identifies issues that are not covered as part of this 482 set of specifications, but that will need to be considered as part of 483 UTF8SMTP deployment. 485 This document does not specify any requirement for normalization. 486 Prudent use of UTF-8 in identifiers will involve sharply restricted 487 forms, for instance case-folded NFKC, but this document does not 488 require such a form anywhere in the protocol. [Note in draft: 489 Whether this non-requirement is adequate is a subject for debate]. 491 5.1. Mailing list header fields 493 All mailing list and mail redistribution related headers are 494 discussed in [EAI-mailing-list]. 496 6. Security Considerations 498 If a user has a non-ASCII mailbox address and an ASCII mailbox 499 address, a digital certificate that identifies that user may have 500 both addresses in the identity. Having multiple email addresses as 501 identities in a single certificate is already supported in PKIX and 502 OpenPGP. 504 Because UTF-8 often requires several octets to encode a single 505 character, internationalized local parts may cause mail addresses to 506 become longer. As specified in [RFC2822], each line of characters 507 MUST be no more 998 octets, excluding the CRLF. 509 Because internationalized local parts may cause email addresses to be 510 longer, processes which parse, store, or handle email addresses or 511 local parts must take extra care not to overflow buffers, truncate 512 addresses, exceed storage allotments, or, when comparing, fail to use 513 the entire length. 515 In this specification, a user could provide an ASCII alternative 516 address for a non-ASCII address. However, it is possible these two 517 address go to different mailboxes, or even different persons. This 518 might not be a protocol problem, but instead be the user's personal 519 choice or administration policy or even be a deliberate attempt to 520 deceive or cause confusion. 522 7. IANA considerations 524 There are no IANA considerations in this document. 526 8. Acknowledgements 528 This document was created by incorporating a good deal of material 529 from an old Internet Draft by Paul Hoffman [Hoffman-utf8-headers]. 530 While many of the concepts and details have changed, the 531 contributions from that draft are greatly appreciated. 533 Most of the content of this document is provided by John C Klensin. 534 Also some significant comments and suggestions were received from 535 Charles H. Lindsey, Kari Hurtta, Chris Newman, Yangwoo KO, Yoshiro 536 YONEYA, and other members of the JET team and were incorporated into 537 the document. The editor is much great thanks to their contribution 538 sincerely. 540 9. Edit history 542 This section is used for tracking the update of this document. Will 543 be removed after finalize. 545 9.1. draft-ietf-eai-utf8header-06 547 1. ABNF revise. 548 2. Sentences modified 549 3. Add paragraph in Section 6 550 4. Add paragraph in Section 1.2 551 5. Modify Section 4.6 553 9.2. draft-ietf-eai-utf8header-05 555 1. ABNF revise. 556 2. Remove original the section 4 (Pre-requirement) 557 3. Add UTF8SMTP message (Section 4.6) 559 9.3. draft-ietf-eai-utf8header-04 561 1. ABNF revise. 562 2. Modify uFor description in Section 4.5 564 9.4. draft-ietf-eai-utf8header-03 566 1. Editrial changes on terms and english. 567 2. ABNF revise. 568 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 569 "<" and ">". 570 4. Remove the "Header-Type" header. 571 5. Add uFor description in Section 4.5 572 6. Remove the content in IANA considerations since "Header-Type" is 573 removed. 575 9.5. draft-ietf-eai-utf8header-02 577 1. Editrial changes on terms and english. 578 2. Change the header name "UTF8SMTP" to "Header-Type", and ABNF 579 revise. 580 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 581 "[" and "]". 583 4. IANA considerations section rewrite. 585 9.6. draft-ietf-eai-utf8header-01 587 1. ABNF revise. 588 2. Terminology sync with overview document. 589 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 590 "{" and "}". 591 4. add IANA considerations to register the new 2822 header 592 "UTF8SMTP". 593 5. add Security considerations about relation of UTF8SMTP address to 594 ALT-ADDRESS. 596 9.7. draft-ietf-eai-utf8header-00 598 1. ABNF added. 599 2. Editrial changes. 600 3. Sent it as WG document. 602 9.8. draft-yeh-ima-utf8header-01 604 1. Section re-arranged. 605 2. Remove content are not below to this document. 607 10. References 609 10.1. Normative References 611 [ASCII] American National Standards Institute (formerly United 612 States of America Standards Institute), "USA Code for 613 Information Interchange", ANSI X3.4-1968, 1968. 615 ANSI X3.4-1968 has been replaced by newer versions with 616 slight modifications, but the 1968 version remains 617 definitive for the Internet. 619 [EAI-SMTP-extension] 620 Yao, J., Ed. and Wei. Mao, "SMTP extension for 621 internationalized email address", 622 draft-ietf-eai-smtpext-06.txt (work in progress), 623 June 2007. 625 [EAI-framework] 626 Klensin, J. and Y. Ko, "Overview and Framework of 627 Internationalized Email Address Delivery", 628 draft-ietf-eai-framework-05.txt (work in progress), 629 Feburary 2007. 631 [EAI-mailing-list] 632 Gellens, Randall., "Mailing Lists and Internationalized 633 Email Addresses", draft-ietf-eai-mailinglist-01.txt (work 634 in progress), January 2007. 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 640 April 2001. 642 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 643 April 2001. 645 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 646 10646", STD 63, RFC 3629, November 2003. 648 10.2. Informative References 650 [EAI-downgrading] 651 YONEYA, Yoshiro., Ed. and Kazunori. Fujiwara, Ed., 652 "Downgrading mechanism for Internationalized eMail Address 653 (IMA)", draft-ietf-eai-downgrade-03.txt (work in 654 progress), March 2007. 656 [Hoffman-utf8-headers] 657 Hoffman, P., "SMTP Service Extensions or Transmission of 658 Headers in UTF-8 Encoding", 659 draft-hoffman-utf8headers-00.txt (work in progress), 660 December 2003. 662 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 663 Extensions (MIME) Part One: Format of Internet Message 664 Bodies", RFC 2045, November 1996. 666 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 667 Extensions (MIME) Part Two: Media Types", RFC 2046, 668 November 1996. 670 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 671 Part Three: Message Header Extensions for Non-ASCII Text", 672 RFC 2047, November 1996. 674 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 675 4rev1", RFC 3501, March 2003. 677 Author's Address 679 Abel Yang (editor) 680 TWNIC 681 4F-2, No. 9, Sec 2, Roosvelt Rd. 682 Taipei, 100 683 Taiwan 685 Phone: +886 2 23411313 ext 505 686 Email: abelyang@twnic.net.tw 688 Full Copyright Statement 690 Copyright (C) The IETF Trust (2007). 692 This document is subject to the rights, licenses and restrictions 693 contained in BCP 78, and except as set forth therein, the authors 694 retain all their rights. 696 This document and the information contained herein are provided on an 697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 699 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 700 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 701 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Intellectual Property 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Acknowledgment 730 Funding for the RFC Editor function is provided by the IETF 731 Administrative Support Activity (IASA).