idnits 2.17.1 draft-ietf-eai-smtpext-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 577. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An SMTP Client that receives the IMA extension keyword MAY transmit a mailbox name as an internationalized string in UTF-8 form and MAY send an internationalized mail header [IMA-utf8header]. It MAY transmit the domain part of that string in either punycode (derived from the IDNA process) or UTF-8 form. If it sends the domain in UTF-8 form, the original SMTP client SHOULD first verify that the string is valid for a domain name according to IDNA rules. As required by RFC 2821, it MUST not attempt to parse, evaluate, or transform the local part in any way if the IMA SMTP extension is offered by the server. If the IMA SMTP extension is not offered by the Server, the SMTP Client MUST NOT transmit an internationalized address and MUST NOT transmit a mail body which contains internationalized mail headers [IMA-utf8header]. Instead, it MUST either return the message to the user as undeliverable or replace it with the alternate ASCII address. If it is replaced, the replacement MUST be either the ASCII-only address specified with the ALT-ADDRESS parameter or with an address obtained from some algorithmic conversions of the primary address that conforms to the syntax rules of RFC 2821, which is defined in [IMA-downgrading]. -- 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 (May 12, 2006) is 6559 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: 'Ldh-str' is mentioned on line 224, but not defined == Unused Reference: 'ASCII' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 533, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Normative reference to a draft: ref. 'IMA-overview' -- No information found for draft-yeh-utf8headers - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IMA-utf8header' ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-01) exists of draft-yoneya-ima-downgrade-00 Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao, Ed. 3 Internet-Draft W. Mao, Ed. 4 Expires: November 13, 2006 CNNIC 5 May 12, 2006 7 SMTP extension for internationalized email address 8 draft-ietf-eai-smtpext-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 9, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Internationalized eMail Address (IMA) includes two parts, the local 42 part and the domain part. The way email addresses are used by 43 protocols are different from the way domain names are used. The most 44 critical difference is that emails are delivered through a chain of 45 peering clients and servers while domain names are resolved by name 46 servers by looking up their own tables. In addition to this, email 47 transport protocols SMTP and ESMTP provide a negotiation mechanism 48 through which clients can make decisions for further processing. So 49 IMA is different from the internationalized domain name (IDN). IMA 50 can be solved by exploiting the negotiation mechanism while IDN can 51 not use the negotiation mechanism. So IMA should be solved in the 52 mail transport-level using the negotiation mechanism, which is an 53 architecturally desirable approach. This document specifies the use 54 of SMTP extension for IMA delivery. It also mentions the backward 55 compatible mechanism for downgrade procedure, as specified in an 56 associated specification. The protocol proposed here is MTA-level 57 solution which is feasible, architecturally more elegant, and not as 58 difficult to deploy in relevant communities. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 64 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 67 2.1. Framework for the Internationalization Extension . . . . . 4 68 2.2. The Address Internationalization Service Extension . . . . 4 69 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 5 70 2.4. The ALT-ADDRESS and ATOMIC parameter . . . . . . . . . . . 6 71 2.5. Additional ESMTP Changes and Clarifications . . . . . . . 8 72 2.5.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 8 73 2.5.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . 8 74 2.5.3. Mailing List Question . . . . . . . . . . . . . . . . 8 75 2.5.4. Message Header Label . . . . . . . . . . . . . . . . . 8 76 3. Potential problems . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1. Impact to IRI . . . . . . . . . . . . . . . . . . . . . . 9 78 3.2. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.3. Impact to RFC 2476 and many email related RFC . . . . . . 9 80 4. Implementation Advice . . . . . . . . . . . . . . . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Intellectual Property and Copyright Statements . . . . . . . . . . 14 90 1. Introduction 92 1.1. Role of this specification 94 An overview document [IMA-overview] specifies the requirements for, 95 and components of, full internationalization of electronic mail. 96 This document specifies an element of that work, specifically the 97 definition of an SMTP extension [RFC1869] for IMA transport delivery. 99 1.2. Proposal Context 101 In order to use internationalized email addresses, we need to 102 internationalize both the domain part and the local part of the email 103 address. Domain part of the email address has been internationalized 104 through IDNA [RFC3490]. But the local part of the email address 105 still remains as non-internationalized. 107 The syntax of Internet email addresses is restricted to a subset of 108 7-bit ASCII for the domain-part, with a less-restricted subset for 109 the local-part. These restrictions are specified in RFC 2821 110 [RFC2821]. To be able to deliver internationalized email through 111 SMTP servers, we need to upgrade SMTP server to be able to carry IMA. 112 Since older SMTP servers and the mail-reading clients and other 113 systems that are downstream from them may not be prepared to handle 114 these extended addresses, an SMTP extension is specified to identify 115 and protect the addressing mechanism. 117 This specification describes a change to the email transport 118 mechanism that permits IMA in both the envelope and header fields of 119 messages. The context for the change is described in [IMA-overview] 120 and the details of the header changes are described in [IMA- 121 utf8header]. 123 1.3. Terminology 125 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 126 and "MAY" in this document are to be interpreted as described in RFC 127 2119 [RFC2119]. 129 All specialized terms used in this specification are defined in the 130 IMA overview [IMA-overview] or in [RFC2821] and [RFC2822]. 132 This document is being discussed on the IMA mailing list. See 133 https://www1.ietf.org/mailman/listinfo/ima for information about 134 subscribing. The list's archive is at 135 http://www1.ietf.org/mail-archive/web/ima/index.html. 137 2. Mail Transport-level Protocol 139 2.1. Framework for the Internationalization Extension 141 The following service extension is defined: 143 1. The name of the SMTP service extension is "Internationalized 144 Email and Extensions"; 145 2. The EHLO keyword value associated with this extension is 146 "IEmail"; 147 3. No parameter values are defined for this EHLO keyword value. In 148 order to permit future (although unanticipated) extensions, the 149 EHLO response MUST NOT contain any parameters for that keyword. 150 If a parameter appears, the SMTP client that is conformant to 151 this version of this specification MUST treat the ESMTP response 152 as if the IMA keyword did not appear. 153 4. Two optional parameters are added to the SMTP MAIL and RCPT 154 commands. The first parameter is named as ALT-ADDRESS. The 155 second is ATOMIC. The "ALT-ADDRESS" requires an all-ASCII 156 address as a substitute for the internationalized (UTF-8 coded) 157 address that we call the primary address; you can learn more in 158 [IMA-overview] or [IMA-downgrading]. The value of "ALT-ADDRESS" 159 may be set by sender or be gotten by using some algorithmic 160 transformation according to the value of "ATOMIC". The "ATOMIC" 161 has one of two values: y or n. The parameter "ATOMIC" is 162 designed to assert whether the address is atomic, which means 163 that the primary address(IMA) can be safely transformed or 164 converted to the respect ASCII email address via ACE (ASCII 165 Compatible Encoding) if the value is 'y' or not if the value is 166 'n'. 167 5. No additional SMTP verbs are defined by this extension. 168 6. Servers offering this extension MUST provide support for, and 169 announce, the 8BITMIME extension [RFC1652]. 171 2.2. The Address Internationalization Service Extension 173 An SMTP Server that announces this extension MUST be prepared to 174 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 175 specifies that a "mailbox" may appear. That string must be parsed 176 only as specified in RFC 2821, i.e., by separating the mailbox into 177 source route, local part and domain part, using only the characters 178 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 179 there. Once isolated by this parsing process, the local part MUST be 180 treated as opaque unless the SMTP Server is the final delivery MTA. 181 Any domain names that are to be looked up in the DNS MUST be 182 processed into the form as specified in IDNA [RFC3490] by means of 183 the ToASCII() operation unless they are already in that form. Any 184 domain names that are to be compared to local strings SHOULD be 185 checked for validity and then MUST be compared as specified in 186 section 3.4 of IDNA. 188 An SMTP Client that receives the IMA extension keyword MAY transmit a 189 mailbox name as an internationalized string in UTF-8 form and MAY 190 send an internationalized mail header [IMA-utf8header]. It MAY 191 transmit the domain part of that string in either punycode (derived 192 from the IDNA process) or UTF-8 form. If it sends the domain in 193 UTF-8 form, the original SMTP client SHOULD first verify that the 194 string is valid for a domain name according to IDNA rules. As 195 required by RFC 2821, it MUST not attempt to parse, evaluate, or 196 transform the local part in any way if the IMA SMTP extension is 197 offered by the server. If the IMA SMTP extension is not offered by 198 the Server, the SMTP Client MUST NOT transmit an internationalized 199 address and MUST NOT transmit a mail body which contains 200 internationalized mail headers [IMA-utf8header]. Instead, it MUST 201 either return the message to the user as undeliverable or replace it 202 with the alternate ASCII address. If it is replaced, the replacement 203 MUST be either the ASCII-only address specified with the ALT-ADDRESS 204 parameter or with an address obtained from some algorithmic 205 conversions of the primary address that conforms to the syntax rules 206 of RFC 2821, which is defined in [IMA-downgrading]. 208 2.3. Extended Mailbox Address Syntax 210 RFC 2821, section 4.1.2, defines the syntax of a mailbox as 212 Mailbox = Local-part "@" Domain 214 Local-part = Dot-string / Quoted-string 215 ; MAY be case-sensitive 217 Dot-string = Atom *("." Atom) 219 Atom = 1*atext 221 Quoted-string = DQUOTE *qcontent DQUOTE 223 Domain = (sub-domain 1*("." sub-domain)) / address-literal 224 sub-domain = Let-dig [Ldh-str] 226 The key changes made by this specification are, informally, to 228 o Change the definition of "sub-domain" to permit either the 229 definition above or a UTF-8 string representing a DNS label that 230 is conformant with IDNA [RFC3490]. That label MUST NOT contain 231 the characters "@" or ".", even though those characters can 232 normally be inserted into a DNS label. 233 o Change the definition of "Atom" to permit either the definition 234 above or a UTF-8 string. That string MUST NOT contain any of the 235 ASCII characters (either graphics or controls) that are not 236 permitted in "atext"; it is otherwise unrestricted. 238 According to the description above, define the syntax of an IMA 239 mailbox with ABNF [RFC4234] as 241 Mailbox = Local-part "@" Domain 243 Local-part = Dot-string / Quoted-string 244 ; MAY be case-sensitive 246 Dot-string = Atom *("." Atom) 248 Atom = 1*Ucharacter 249 Ucharacter = atext / UTF8-2 / UTF8-3 / UTF8-4 251 Quoted-string = DQUOTE *qcontent DQUOTE 253 Domain = (sub-domain 1*("." sub-domain)) / address-literal 254 sub-domain = ULet-dig [ULdh-str] 256 ULet-dig = Let-dig / Non-ASCII 258 ULdh-str = *( ALPHA / DIGIT / "-" / Non-ASCII) ULet-dig 260 Non-ASCII = UTF8-2 / UTF8-3 / UTF8-4 261 ; UTF-8 characters prohibited by nameprep 262 ; MUST NOT be used. 264 Where "atext", "qcontent" and "DQUOTE" are defined in [RFC2822], 265 "Let-dig", "Ldh-str" and "address-literal" are defined in [RFC2821] 266 and UTF8-2, UTF8-3 and UTF8-4 are defined in [RFC3629]. The value of 267 "Local-part" should pass Stringprep [RFC3454]; The value of "domain" 268 should be verified with [RFC3490]; If failed, The value of "Local- 269 part" and "domain", the email address can not be regarded as the 270 valid email address. 272 2.4. The ALT-ADDRESS and ATOMIC parameter 274 If the IMA extension is offered, the syntax of the SMTP MAIL and RCPT 275 commands is extended to support both the optional "ALT-ADDRESS" and 276 "ATOMIC" parameter. 278 The "ALT-ADDRESS" requires an all-ASCII address, which may set by the 279 sender or some algorithmic transformation. 281 The big problem with applying an ACE to all local-parts is that the 282 sending or converting system doesn't know if there are some specific 283 data or instructions embedded in the address that the ACE process 284 would hide. Some SMTP servers may depend on these specific data or 285 instructions to do some operations while the local parts applied with 286 ACE will lose or hide these data or instructions. SMTP [RFC2821] 287 prohibits SMTP relays from converting local parts because the level 288 of SMTP relays' knowledge on the structure of local parts is assumed 289 to be zero. However, we can raise the knowledge level by supplying 290 additional information. Many human users' email addresses do not 291 have any embedded structure processed by the final delivery MTA. In 292 that case, the sender can specify that these email addresses are safe 293 to be converted in predefined way. The final delivery SMTP server 294 can revert the addresses even though they are as in all ASCII form. 295 In such cases, a potential recipient might be able to tell someone to 296 whom the address is given "it is ok, there is no embedded information 297 here and you can convert it to an ACE address without danger". If 298 the recipient says that, then if the sender can pass that assertion 299 along to his or her own (originator) MTA and the MTA can pass it down 300 the line, then an MTA that needs to do downgrading would know that 301 ACE-encoding is safe. The "ATOMIC" parameter is designed for the 302 above aim. Transmission of local-parts of UTF-8 avoids having to 303 deal with the problem. 305 The use of the ALT-ADDRESS will be according to the following 306 priority if SMTP servers can not support IMA capability. If the 307 sender has already set the ALT-ADDRESS value in spite of the value of 308 ATOMIC, the client SMTP server will use this address as the email 309 address when the SMTP server does the subsequent operations. If the 310 ALT-ADDRESS value is not set by the sender but the value of ATOMIC is 311 'y', the sender SMTP server should apply some algorithmic 312 transformation such as punycode to the entire local part of IMA; IDNA 313 should also be applied to the domain part of IMA; these operations 314 will get an ASCII email address for the subsequent SMTP operations 315 related to the email address. If the ALT-ADDRESS value is not set by 316 the sender and the value of ATOMIC is 'n' which means that the local 317 part of IMA can not be converted to the ASCII email address safely, 318 the email must be bounced to the original sender. 320 The suggested algorithmic transformation is punycode if the value of 321 ALT-ADDRESS is not set by sender and the value of ATOMIC is 'y' when 322 SMTP servers can not support IMA. Since the prefix "xn--" had been 323 used for IDNA, it is better that other prefix such as "bq--" is used 324 for the local part of converted version of the primary address to 325 avoid the potential confusion. 327 2.5. Additional ESMTP Changes and Clarifications 329 The mail transport process involves addresses ("mailboxes") and 330 domain names in contexts in addition to the MAIL and RCPT commands 331 and extended alternatives to them. In general, the rule is that, 332 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 333 used for the entire string; when RFC 2821 specifies a domain name, 334 the name should be in punycode form if its raw form is non-ASCII. 336 The following subsections list and discuss all of the relevant cases. 338 Support and use of this extension requires support for 8BITMIME. It 339 means that 8BITMIME must be advertised by the IMA capability SMTP 340 server. 342 2.5.1. The Initial SMTP Exchange 344 When an SMTP or ESMTP connection is opened, the server sends a 345 "banner" response consisting of the 220 reply code and some 346 information. The client then sends the EHLO command. Since the 347 client cannot know whether the server supports IMA until after it 348 receives the response from EHLO, any domain names that appear in this 349 dialogue, or in responses to EHLO, must be in hostname form, i.e., 350 internationalized ones must be in punycode form. 352 2.5.2. Trace Fields 354 Internationalized domain names in Received fields must be transmitted 355 in the punycode form. Addresses in "for" clauses need further 356 examination and might be treated differently depending on [IMA- 357 utf8header]. The reasoning in the introductory portion of [IMA- 358 overview] strongly suggests that these addresses be in UTF-8 form, 359 rather than some specialized encoding. 361 2.5.3. Mailing List Question 363 How a mixture of traditional and internationalized addresses on a 364 mailing list will impact message flows, error reports, and delivery 365 notifications in all plausible combinations of IMA capability and un- 366 capability servers is still not clear. This is an issue, which we 367 can delve into in detail in the future discussion. We will proposed 368 the detail solution to it in another document, and do some 369 experiments to find the best solution to it. 371 2.5.4. Message Header Label 373 There is a hot discussion about message header label when SMTP 374 messages are transmitted on wire. How to identify them and 375 distinguish them from the normal message. Many referred the famous 376 "MIME-Version:1.0" as the example. In order to get the robustness in 377 the absence of context, we should consider the issue whether or not 378 we need a mechanism(such as self-label) or some indicator to 379 distinguish or recognize the format of a "stored" message: new 380 format(i.e. IMA compliant) or old one (i.e. RFC 822 compliant). 381 [Note in draft: The detail discussion of this issue will be available 382 in [IMA-utf8header].] 384 3. Potential problems 386 3.1. Impact to IRI 388 The mailto: schema in IRI [RFC3987] may need to be modified when IMA 389 is standardized. 391 3.2. POP and IMAP 393 While SMTP mainly takes care of the transportation of messages and 394 the header fields on wire, POP essentially handles the retrieval of 395 mail objects from the server by a client. In order to use 396 internationalized user names based on IMA for the retrieval of 397 messages from a mail server using the POP protocol, a new capability 398 should be introduced following the POP3 extension mechanism 399 [RFC2449]. 401 IMAP [RFC3501] uses the traditional user name which is based on 402 ASCII. IMAP should be updated to support the internationalized user 403 names based on IMA for the retrieval of messages from a mail server. 405 3.3. Impact to RFC 2476 and many email related RFC 407 The IMA protocol will impact on many email related RFC such as 408 Message Submission [RFC2476] and SMTP Service Extension for DSNs 409 [RFC3461]. These protocol should be considered when implementing the 410 IMA protocol. 412 4. Implementation Advice 414 In the absence of this extension, SMTP clients and servers are 415 constrained to using only those addresses permitted by RFC 2821. The 416 local parts of those addresses may be made up of any ASCII 417 characters, although certain of them must be quoted as specified 418 there. It is notable in an internationalization context that there 419 is a long history on some systems of using overstruck ASCII 420 characters (a character, a backspace, and another character) within a 421 quoted string to approximate non-ASCII characters. This form of 422 internationalization should be phased out as this extension becomes 423 widely deployed but backward-compatibility considerations require 424 that it continue to be supported. 426 5. IANA Considerations 428 IANA is requested to add "IEmail" to the SMTP extensions registry 429 with the entry pointing to this specification for its definition. 431 6. Security considerations 433 See the extended security considerations discussion in [IMA-overview] 435 7. Acknowledgements 437 Much of the text in the initial version of this document was derived 438 or copied from [Klensin-emailaddr] with the permission of the author. 439 Significant comments and suggestions were received from Xiaodong LEE, 440 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 441 team and were incorporated into the document. Special thanks to 442 those contributors for this version of document, those includes (but 443 not limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald 444 Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon 445 Chung. 447 8. References 449 8.1. Normative References 451 [ASCII] American National Standards Institute (formerly United 452 States of America Standards Institute), "USA Code for 453 Information Interchange", ANSI X3.4-1968, 1968. 455 ANSI X3.4-1968 has been replaced by newer versions with 456 slight modifications, but the 1968 version remains 457 definitive for the Internet. 459 [IMA-overview] 460 Klensin, J. and Y. Ko, "Overview and Framework for 461 Internationalized Email", draft-klensin-ima-framework-01 462 (work in progress), February 2006. 464 [IMA-utf8header] 465 Klensin, J. and J. Yeh, "Transmission of Email Headers in 466 UTF-8 Encoding", draft-yeh-utf8headers-00 (work in 467 progress), October 2005. 469 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 470 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 471 RFC 1652, July 1994. 473 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 474 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 475 November 1995. 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 481 Mechanism", RFC 2449, November 1998. 483 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", 484 RFC 2476, December 1998. 486 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 487 April 2001. 489 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 490 April 2001. 492 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 493 Internationalized Strings ("stringprep")", RFC 3454, 494 December 2002. 496 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 497 Extension for Delivery Status Notifications (DSNs)", 498 RFC 3461, January 2003. 500 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 501 "Internationalizing Domain Names in Applications (IDNA)", 502 RFC 3490, March 2003. 504 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 505 for Internationalized Domain Names in Applications 506 (IDNA)", RFC 3492, March 2003. 508 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 509 4rev1", RFC 3501, March 2003. 511 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 512 10646", RFC 3629, November 2003. 514 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 515 Identifiers (IRIs)", RFC 3987, January 2005. 517 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 518 Specifications: ABNF", RFC 4234, October 2005. 520 8.2. Informative References 522 [IMA-downgrading] 523 YONEYA, Y. and K. Fujiwara, "Downgrade Mechanism for 524 Internationalized Email Address (IMA)", 525 draft-yoneya-ima-downgrade-00 (work in progress), 526 October 2005. 528 [Klensin-emailaddr] 529 Klensin, J., "Internationalization of Email Addresses", 530 draft-klensin-emailaddr-i18n-03 (work in progress), 531 July 2005. 533 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 534 Extensions (MIME) Part One: Format of Internet Message 535 Bodies", RFC 2045, November 1996. 537 Authors' Addresses 539 Jiankang YAO (editor) 540 CNNIC 541 No.4 South 4th Street, Zhongguancun 542 Beijing 544 Phone: +86 10 58813007 545 Email: yaojk@cnnic.cn 547 Wei MAO (editor) 548 CNNIC 549 No.4 South 4th Street, Zhongguancun 550 Beijing 552 Phone: +86 10 58813055 553 Email: mao@cnnic.cn 555 Intellectual Property Statement 557 The IETF takes no position regarding the validity or scope of any 558 Intellectual Property Rights or other rights that might be claimed to 559 pertain to the implementation or use of the technology described in 560 this document or the extent to which any license under such rights 561 might or might not be available; nor does it represent that it has 562 made any independent effort to identify any such rights. Information 563 on the procedures with respect to rights in RFC documents can be 564 found in BCP 78 and BCP 79. 566 Copies of IPR disclosures made to the IETF Secretariat and any 567 assurances of licenses to be made available, or the result of an 568 attempt made to obtain a general license or permission for the use of 569 such proprietary rights by implementers or users of this 570 specification can be obtained from the IETF on-line IPR repository at 571 http://www.ietf.org/ipr. 573 The IETF invites any interested party to bring to its attention any 574 copyrights, patents or patent applications, or other proprietary 575 rights that may cover technology that may be required to implement 576 this standard. Please address the information to the IETF at 577 ietf-ipr@ietf.org. 579 Disclaimer of Validity 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 584 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 585 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 586 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Copyright Statement 591 Copyright (C) The Internet Society (2006). This document is subject 592 to the rights, licenses and restrictions contained in BCP 78, and 593 except as set forth therein, the authors retain all their rights. 595 Acknowledgment 597 Funding for the RFC Editor function is currently provided by the 598 Internet Society.