idnits 2.17.1 draft-yao-ima-smtpext-02.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 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. ** 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. 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. 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. -- 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 24, 2006) is 6636 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 219, but not defined == Unused Reference: 'ASCII' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 493, 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 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-01) exists of draft-yoneya-ima-downgrade-00 Summary: 10 errors (**), 0 flaws (~~), 8 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 X. Lee, Ed. 4 Expires: August 28, 2006 CNNIC 5 February 24, 2006 7 SMTP extension for internationalized email address 8 draft-yao-ima-smtpext-02.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 August 28, 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 . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 8 77 3.1. Impact to IRI . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 9 79 4. Implementation Advice . . . . . . . . . . . . . . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 Intellectual Property and Copyright Statements . . . . . . . . . . 13 89 1. Introduction 91 1.1. Role of this specification 93 An overview document [IMA-overview] specifies the requirements for, 94 and components of, full internationalization of electronic mail. 95 This document specifies an element of that work, specifically the 96 definition of an SMTP extension [RFC1869] for IMA transport delivery. 98 1.2. Proposal Context 100 In order to use internationalized email addresses, we need to 101 internationalize both the domain part and the local part of the email 102 address. Domain part of the email address may be internationalized 103 through IDNA [RFC3490]. But the local part of the email address 104 still remains as non-internationalized. 106 The syntax of Internet email addresses is restricted to a subset of 107 7-bit ASCII for the domain-part, with a less-restricted subset for 108 the local-part. These restrictions are specified in RFC 2821 109 [RFC2821]. To be able to deliver internationalized email through 110 SMTP servers, we need to upgrade SMTP server to be able to carry IMA. 111 Since older SMTP servers and the mail-reading clients and other 112 systems that are downstream from them may not be prepared to handle 113 these extended addresses, an SMTP extension is specified to identify 114 and protect the addressing mechanism. 116 This specification describes a change to the email transport 117 mechanism that permits IMA in both the envelope and header fields of 118 messages. The context for the change is described in [IMA-overview] 119 and the details of the header changes are described in [IMA- 120 utf8header]. 122 1.3. Terminology 124 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 125 and "MAY" in this document are to be interpreted as described in RFC 126 2119 [RFC2119]. 128 All specialized terms used in this specification are defined in the 129 IMA overview [IMA-overview] or in [RFC2821] and [RFC2822]. 131 This document is being discussed on the IMA mailing list. See 132 https://www1.ietf.org/mailman/listinfo/ima for information about 133 subscribing. The list's archive is at 134 http://www1.ietf.org/mail-archive/web/ima/index.html. 136 2. Mail Transport-level Protocol 138 2.1. Framework for the Internationalization Extension 140 The following service extension is defined: 142 1. The name of the SMTP service extension is "Internationalized 143 Email and Extensions"; 144 2. The EHLO keyword value associated with this extension is 145 "IEmail"; 146 3. No parameter values are defined for this EHLO keyword value. In 147 order to permit future (although unanticipated) extensions, the 148 EHLO response MUST NOT contain any parameters for that keyword. 149 If a parameter appears, the SMTP client that is conformant to 150 this version of this specification MUST treat the ESMTP response 151 as if the IMA keyword did not appear. 152 4. Two optional parameters are added to the SMTP MAIL and RCPT 153 commands. The first parameter is named as ALT-ADDRESS. The 154 second is ATOMIC. The "ALT-ADDRESS" requires an all-ASCII 155 address as a substitute for the internationalized (UTF-8 coded) 156 address that we call the primary address; you can learn more in 157 [IMA-overview] or [IMA-downgrading]. The value of "ALT-ADDRESS" 158 may be set by sender or be gotten by using some algorithmic 159 transformation according to the value of "ATOMIC". The "ATOMIC" 160 has one of two values: y or n. The parameter "ATOMIC" is 161 designed to assert whether the address is atomic, which means 162 that the the primary address(IMA) can be safely transformed or 163 converted to the respect ASCII email address via ACE (ASCII 164 Compatible Encoding) if the value is 'y' or not if the value is 165 'n'. 166 5. No additional SMTP verbs are defined by this extension. 167 6. Servers offering this extension MUST provide support for, and 168 announce, the 8BITMIME extension [RFC1652]. 170 2.2. The Address Internationalization Service Extension 172 An SMTP Server that announces this extension MUST be prepared to 173 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 174 specifies that a "mailbox" may appear. That string must be parsed 175 only as specified in RFC 2821, i.e., by separating the mailbox into 176 source route, local part and domain part, using only the characters 177 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 178 there. Once isolated by this parsing process, the local part MUST be 179 treated as opaque unless the SMTP Server is the final delivery MTA. 180 Any domain names that are to be looked up in the DNS MUST be 181 processed into punycode [RFC3492] form as specified in IDNA [RFC3490] 182 unless they are already in that form. Any domain names that are to 183 be compared to local strings SHOULD be checked for validity and then 184 MUST be compared as specified in IDNA. 186 An SMTP Client that receives the IMA extension keyword MAY transmit a 187 mailbox name as an internationalized string in UTF-8 form. It MAY 188 transmit the domain part of that string in either punycode (derived 189 from the IDNA process) or UTF-8 form. If it sends the domain in 190 UTF-8 form, the original SMTP client SHOULD first verify that the 191 string is valid for a domain name according to IDNA rules. As 192 required by RFC 2821, it MUST not attempt to parse, evaluate, or 193 transform the local part in any way if the IMA SMTP extension is 194 offered by the server. If the IMA SMTP extension is not offered by 195 the Server, the SMTP Client MUST not transmit an internationalized 196 address. Instead, it MUST either return the message to the user as 197 undeliverable or replace it with the alternate ASCII address. If it 198 is replaced, the replacement MUST be either the ASCII-only address 199 specified with the ALT-ADDRESS parameter or with an address obtained 200 from some algorithmic conversions of the primary address that 201 conforms to the syntax rules of RFC 2821. 203 2.3. Extended Mailbox Address Syntax 205 RFC 2821, section 4.1.2, defines the syntax of a mailbox as 207 Mailbox = Local-part "@" Domain 209 Local-part = Dot-string / Quoted-string 210 ; MAY be case-sensitive 212 Dot-string = Atom *("." Atom) 214 Atom = 1*atext 216 Quoted-string = DQUOTE *qcontent DQUOTE 218 Domain = (sub-domain 1*("." sub-domain)) / address-literal 219 sub-domain = Let-dig [Ldh-str] 221 The key changes made by this specification are, informally, to 223 o Change the definition of "sub-domain" to permit either the 224 definition above or a UTF-8 string representing a DNS label that 225 is conformant with IDNA [RFC3490]. That label MUST NOT contain 226 the characters "@" or ".", even though those characters can 227 normally be inserted into a DNS label. 229 o Change the definition of "Atom" to permit either the definition 230 above or a UTF-8 string. That string MUST NOT contain any of the 231 ASCII characters (either graphics or controls) that are not 232 permitted in "atext"; it is otherwise unrestricted. 234 According to the description above, define the syntax of an IMA 235 mailbox with ABNF [RFC2234] as 237 Mailbox = Local-part "@" Domain 239 Local-part = Dot-string / Quoted-string 240 ; MAY be case-sensitive 242 Dot-string = Atom *("." Atom) 244 Atom = 1*Ucharacter 245 Ucharacter = 248 Quoted-string = DQUOTE *qcontent DQUOTE 250 Domain = (sub-domain 1*("." sub-domain)) / address-literal 251 sub-domain = Let-dig [Ldh-str] / 252 254 2.4. The ALT-ADDRESS and ATOMIC parameter 256 If the IMA extension is offered, the syntax of the SMTP MAIL and RCPT 257 commands is extended to support both the optional "ALT-ADDRESS" and 258 "ATOMIC" parameter. 260 The "ALT-ADDRESS" requires an all-ASCII address, which may set by 261 sender or some algorithmic transformation. 263 The big problem with applying an ACE to all local-parts is that the 264 sending or converting system doesn't know if there are data or 265 instructions embedded in the address that the ACE process would hide. 266 SMTP [RFC2821] prohibits SMTP relays from converting local parts 267 because the level of SMTP relays' knowledge on the structure of local 268 parts is assumed to be zero. However, we can raise the knowledge 269 level by supplying additional information. Many human users' email 270 addresses do not have any embedded structure processed by the final 271 delivery MTA. In that case, sender can specify that these email 272 addresses are safe to be converted in predefined way. The final 273 delivery SMTP server can revert the addresses even though they are as 274 in all ASCII form. In such cases, a potential recipient might be 275 able to tell someone to whom the address is given "it is ok, there is 276 no embedded information here and you can convert it to an ACE address 277 without danger". If the recipient says that, then if the sender can 278 pass that assertion along to his or her own (originator) MTA and the 279 MTA can pass it down the line, then an MTA that needs to do 280 downgrading would know that ACE-encoding is safe. The "ATOMIC" 281 parameter is designed for the above aim. Transmission of local-parts 282 of UTF-8 avoids having to deal with the problem. 284 The use of the ALT-ADDRESS will be according to the following 285 priority if SMTP servers can not support IMA capability. If the 286 sender has already set the ALT-ADDRESS value in spite of the value of 287 ATMOIC, the client SMTP server will use this address as the email 288 address when the SMTP server does the subsequent operations. If the 289 ALT-ADDRESS value is not set by the sender but the value of ATOMIC is 290 'y', the sender SMTP server can apply some algorithmic transformation 291 such as punycode to the entire local part of IMA; IDNA may also be 292 applied to the domain part of IMA; these operations will get an ASCII 293 email address for the subsequent SMTP operations related to the email 294 address. If the ALT-ADDRESS value is not set by the sender and the 295 value of ATOMIC is 'n' which means that the local part of IMA can not 296 be converted to the ASCII email address safely, the email must be 297 bounced to the original sender. 299 The suggested algorithmic transformation is punycode if the value of 300 ALT-ADDRESS is not set by sender and the vallue of ATMOIC is 'y' when 301 SMTP servers can not support IMA. Since the prefix "xn--" had been 302 used for IDNA, it is better that other prefix such as "bq--" is used 303 for the local part of converted version of the primary address to 304 avoid the potential confusion. 306 2.5. Additional ESMTP Changes and Clarifications 308 The mail transport process involves addresses ("mailboxes") and 309 domain names in contexts in addition to the MAIL and RCPT commands 310 and extended alternatives to them. In general, the rule is that, 311 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 312 used for the entire string; when RFC 2821 specifies a domain name, 313 the name should be in punycode form if its raw form is non-ASCII. 315 The following subsections list and discuss all of the relevant cases. 317 Support and use of this extension requires support for 8BITMIME. It 318 means that 8BITMIME should be advertised by the IMA capability SMTP 319 server. 321 2.5.1. The Initial SMTP Exchange 323 When an SMTP or ESMTP connection is opened, the server sends a 324 "banner" response consisting of the 220 reply code and some 325 information. The client then sends the EHLO command. Since the 326 client cannot know whether the server supports IMA until after it 327 receives the response from EHLO, any domain names that appear in this 328 dialogue, or in responses to EHLO, must be in hostname form, i.e., 329 internationalized ones must be in punycode form. 331 2.5.2. Trace Fields 333 Internationalized domain names in Received fields should be 334 transmitted in punycode form. Addresses in "for" clauses need 335 further examination and might be treated differently depending on 336 [IMA-utf8header]. The reasoning in the introductory portion of [IMA- 337 overview] strongly suggests that these addresses be in UTF-8 form, 338 rather than some specialized encoding. 340 2.5.3. Mailing List Question 342 How a mixture of traditional and internationalized addresses on a 343 mailing list will impact message flows, error reports, and delivery 344 notifications in all plausible combinations of IMA capability and un- 345 capability servers is still not clear. This is an issue, which we 346 can delve into in detail in the future proposed IEE working group. 347 We will proposed the detail solution to it in another document, and 348 do some experiments to find the best solution to it. 350 2.5.4. Message Header Label 352 There is a hot discussion about message header label when SMTP 353 messages are transmitted on wire. How to identify them and 354 distinguish them from the normal message. Many referred the famous 355 "MIME-Version:1.0" as the example. In order to get the robustness in 356 the absence of context, we should consider the issue whether or not 357 we need a mechanism(such as self-label) or some indicator to 358 distinguish or recognize the format of a "stored" message: new 359 format(i.e. IMA compliant) or old one (i.e. RFC 822 compliant). 360 More detailed discussion is needed after the future proposed IEE 361 working group is formed. 363 3. Potential problems 365 3.1. Impact to IRI 367 The mailto: schema in IRI [RFC3987] may need to be modified when IMA 368 is standardized. 370 3.2. POP and IMAP 372 While SMTP mainly takes care of the transportation of messages and 373 the header fields on wire, POP essentially handles the retrieval of 374 mail objects from the server by a client. In order to use 375 internationalized user names based on IMA for the retrieval of 376 messages from a mail server using the POP protocol, a new capability 377 should be introduced following the POP3 extension mechanism 378 [RFC2449]. 380 IMAP [RFC3501] uses the traditional user name which is based on 381 ASCII. IMAP should be updated to support the internationalized user 382 names based on IMA for the retrieval of messages from a mail server. 384 4. Implementation Advice 386 In the absence of this extension, SMTP clients and servers are 387 constrained to using only those addresses permitted by RFC 2821. The 388 local parts of those addresses may be made up of any ASCII 389 characters, although certain of them must be quoted as specified 390 there. It is notable in an internationalization context that there 391 is a long history on some systems of using overstruck ASCII 392 characters (a character, a backspace, and another character) within a 393 quoted string to approximate non-ASCII characters. This form of 394 internationalization should be phased out as this extension becomes 395 widely deployed but backward-compatibility considerations require 396 that it continue to be supported. 398 5. IANA Considerations 400 IANA is requested to add "IEmail" to the SMTP extensions registry 401 with the entry pointing to this specification for its definition. 403 6. Security considerations 405 See the extended security considerations discussion in [IMA-overview] 407 7. Acknowledgements 409 Much of the text in the initial version of this document was derived 410 or copied from [Klensin-emailaddr] with the permission of the author. 411 Significant comments and suggestions were received from Nai-Wen Hsu, 412 Yangwoo KO, Yoshiro YONEYA, and other members of the JET team and 413 were incorporated into the document. Special thanks to those 414 contributors for this version of document, those includes (but not 415 limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald 416 Tveit Alvestrand, Martin Duerst, Edmon Chung. 418 8. References 420 8.1. Normative References 422 [ASCII] American National Standards Institute (formerly United 423 States of America Standards Institute), "USA Code for 424 Information Interchange", ANSI X3.4-1968, 1968. 426 ANSI X3.4-1968 has been replaced by newer versions with 427 slight modifications, but the 1968 version remains 428 definitive for the Internet. 430 [IMA-overview] 431 Klensin, J. and Y. Ko, "Overview and Framework for 432 Internationalized Email", draft-klensin-ima-framework-01 433 (work in progress), February 2006. 435 [IMA-utf8header] 436 Klensin, J. and J. Yeh, "Transmission of Email Headers in 437 UTF-8 Encoding", draft-yeh-utf8headers-00 (work in 438 progress), October 2005. 440 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 441 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 442 RFC 1652, July 1994. 444 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 445 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 446 November 1995. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 452 Specifications: ABNF", STD 10, RFC 2234, November 1997. 454 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 455 Mechanism", RFC 2449, November 1998. 457 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 458 April 2001. 460 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 461 April 2001. 463 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 464 "Internationalizing Domain Names in Applications (IDNA)", 465 RFC 3490, March 2003. 467 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 468 for Internationalized Domain Names in Applications 469 (IDNA)", RFC 3492, March 2003. 471 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 472 4rev1", RFC 3501, March 2003. 474 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 475 10646", RFC 3629, November 2003. 477 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 478 Identifiers (IRIs)", RFC 3987, January 2005. 480 8.2. Informative References 482 [IMA-downgrading] 483 YONEYA, Y. and K. Fujiwara, "Downgrade Mechanism for 484 Internationalized Email Address (IMA)", 485 draft-yoneya-ima-downgrade-00 (work in progress), 486 October 2005. 488 [Klensin-emailaddr] 489 Klensin, J., "Internationalization of Email Addresses", 490 draft-klensin-emailaddr-i18n-03 (work in progress), 491 July 2005. 493 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 494 Extensions (MIME) Part One: Format of Internet Message 495 Bodies", RFC 2045, November 1996. 497 Authors' Addresses 499 Jiankang YAO (editor) 500 CNNIC 501 No.4 South 4th Street, Zhongguancun 502 Beijing 504 Phone: +86 10 58813007 505 Email: yaojk@cnnic.cn 507 Xiaodong LEE (editor) 508 CNNIC 509 No.4 South 4th Street, Zhongguancun 510 Beijing 512 Phone: +86 10 58813020 513 Email: lee@cnnic.cn 515 Intellectual Property Statement 517 The IETF takes no position regarding the validity or scope of any 518 Intellectual Property Rights or other rights that might be claimed to 519 pertain to the implementation or use of the technology described in 520 this document or the extent to which any license under such rights 521 might or might not be available; nor does it represent that it has 522 made any independent effort to identify any such rights. Information 523 on the procedures with respect to rights in RFC documents can be 524 found in BCP 78 and BCP 79. 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use of 529 such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository at 531 http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention any 534 copyrights, patents or patent applications, or other proprietary 535 rights that may cover technology that may be required to implement 536 this standard. Please address the information to the IETF at 537 ietf-ipr@ietf.org. 539 Disclaimer of Validity 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 544 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 545 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 546 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Copyright Statement 551 Copyright (C) The Internet Society (2006). This document is subject 552 to the rights, licenses and restrictions contained in BCP 78, and 553 except as set forth therein, the authors retain all their rights. 555 Acknowledgment 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.