idnits 2.17.1 draft-klensin-ima-framework-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. ** 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). -- 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 20, 2006) is 6633 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) == Unused Reference: 'I18Nemail-constraints' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC1651' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC2449' is defined on line 635, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'I18Nemail-Exploder' -- No information found for draft-yao-smtpext - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I18Nemail-SMTPext' == Outdated reference: A later version (-01) exists of draft-yeh-ima-utf8headers-00 -- Possible downref: Normative reference to a draft: ref. 'I18Nemail-UTF8' -- Possible downref: Non-RFC (?) normative reference: ref. 'I18Nemail-constraints' == Outdated reference: A later version (-01) exists of draft-yoneya-ima-downgrade-00 -- Possible downref: Normative reference to a draft: ref. 'I18Nemail-downgrade' -- Possible downref: Non-RFC (?) normative reference: ref. 'I18Nemail-ops' ** Obsolete normative reference: RFC 1651 (Obsoleted by RFC 1869) ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- No information found for draft-klensin-ima-imappop-00a - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft 4 Expires: August 24, 2006 Y. Ko 5 MOCOCO, Inc. 6 February 20, 2006 8 Overview and Framework for Internationalized Email 9 draft-klensin-ima-framework-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 24, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Full use of electronic mail throughout the world requires that people 43 be able to use their own names, written correctly in their own 44 languages and scripts, as mailbox names in email addresses. This 45 document introduces a series of specifications and operational 46 suggestions that define mechanisms and protocol extensions needed to 47 fully support internationalized email addresses. These changes 48 include an SMTP extension and extension of email header syntax to 49 accommodate UTF-8 data. The document set also will include 50 discussion of key assumptions and issues in deploying fully 51 internationalized email. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Role of This Specification . . . . . . . . . . . . . . . . 3 57 1.2. Problem statement . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Overview of the Approach . . . . . . . . . . . . . . . . . . . 5 60 3. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Overview of Protocol Extensions and Changes . . . . . . . . . 6 62 4.1. SMTP Extension for Internationalized eMail Address . . . . 6 63 4.2. Transmission of Email Header in UTF-8 Encoding . . . . . . 7 64 4.3. Downgrading Mechanism for Backward Compatibility . . . . . 7 65 5. Downgrading Before and After SMTP Transactions . . . . . . . . 8 66 5.1. Downgrading Before or During Message Submission . . . . . 8 67 5.2. Downgrading or Other Processing After Final SMTP 68 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Advice to Designers and Operators of Mail-receiving Systems . 9 70 7. Internationalization Considerations . . . . . . . . . . . . . 9 71 8. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Impact on IRIs . . . . . . . . . . . . . . . . . . . . . . 10 73 8.2. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 78 12.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 11 79 12.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 Intellectual Property and Copyright Statements . . . . . . . . . . 16 86 1. Introduction 88 In order to use internationalized email addresses, we need to 89 internationalize both domain part and local part of email address. 90 The domain part of email addresses is already internationalized 91 [RFC3490], while the local part is not. Without these extensions, 92 the mailbox name is restricted to a subset of 7-bit ASCII in 93 [RFC2821]. Though MIME enables the transport of non-ASCII data, it 94 does not provide a mechanism for internationalized email address. 95 [RFC2047] defines an encoding mechanism for some specific message 96 header fields to accommodate non-ASCII data. However, it does not 97 address the issue of email addresses that include non-ASCII 98 characters. Without the extensions defined here, or some equivalent 99 set, the only way to incorporate non-ASCII characters in email 100 addresses is to use RFC2047 coding to embed them in the "name 101 phrases" of the relevant headers. Of course, that type of coding is 102 invisible in the message envelope and would not be considered by many 103 to be part of the address at all. 105 1.1. Role of This Specification 107 This document presents the overview and framework for an approach to 108 the next stage of email internationalization. This new stage 109 requires not only internationalization of addresses and headers, but 110 also associated transport and delivery models. The history of 111 developments and design ideas leading to this specification is 112 described in [I18Nemail-history]. 114 This document describes how the various elements of email 115 internationalization fit together and provides a roadmap for 116 navigating the various documents involved. 118 1.2. Problem statement 120 [[anchor1: Note in draft: this section needs very significant 121 reworking for both content and presentation. Changed with -01c, but 122 may still not be good enough]] 124 Though domain names are already internationalized, the 125 internationalized forms are far from general adoption by ordinary 126 users. One of the reasons for this is that we do not yet have fully 127 internationalized naming schemes. Domain names are just one of the 128 various names and identifiers that are required to be 129 internationalized. 131 Email addresses are a particularly important example of where 132 internationalization of domain names alone is not sufficient. Unless 133 email addresses are presented to the user in familiar characters and 134 formats, the user's perception will not be of internationalization 135 and behavior that is culturally friendly. One thing most of us have 136 almost certainly learned from the experience with email usage is that 137 users strongly prefer email addresses that closely resemble names or 138 initials to those involving meaningless strings of letters or 139 numbers. If the names or initials of the names in the email address 140 can be expressed in the native languages and writing systems of the 141 users, the Internet will be perceived as more natural by those whose 142 native language is not written in a subset of a Roman-derived script. 144 Internationalization of email addresses is not merely a matter of 145 changing the SMTP envelope, or of modifying the From, To, and Cc 146 headers, or of permitting upgraded mail user agents (MUAs) to decode 147 a special coding and display local characters. To be perceived as 148 usable by end users, the addresses must be internationalized, and 149 handled consistently, in all of the contexts in which they occur. 150 That requirement has far-reaching implications: collections of 151 patches and workarounds are not adequate. Even if they were 152 adequate, that approach risks an assortment of implementations with 153 different sets of patches and workarounds having been applied with 154 consequent user confusion about what is actually be run and 155 supported. Instead, we need to build a fully internationalized email 156 environment, focusing on permitting efficient communication among 157 those who share a language or other community (see [I18Nemail- 158 constraints] for an extended discussion of this optimization). That, 159 in turn, implies changes to the mail header environment to permit the 160 full range of Unicode characters where that makes sense, an SMTP 161 extension to permit UTF-8 [RFC3629] mail addressing and delivery of 162 those extended headers, and (finally) a requirement for support of 163 the 8BITMIME option so that all of this can be transported through 164 the mail system without having to overcome the limitation that 165 headers do not have content-transfer-encodings. 167 1.3. Terminology 169 This document assumes a reasonable understanding of the protocols and 170 terminology of the core email standards as documented in [RFC2821] 171 and [RFC2822]. 173 Much of the description in this document depends on the abstractions 174 of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). 175 However, it is important to understand that those terms and the 176 underlying concepts postdate the design of the Internet's email 177 architecture and the "protocols on the wire" principle. That email 178 architecture, as it has evolved, and the "wire" principle have 179 prevented any strong and standardized distinctions about how MTAs and 180 MUAs interact on a given origin or destination host (or even whether 181 they are separate). 183 In this document, an address is "all-ASCII" if every character in the 184 address is in the ASCII character repertoire [ASCII]; an address is 185 "non-ASCII" if any character is not in the ASCII character 186 repertoire. The term "all-ASCII" is also applied to other protocol 187 elements when the distinction is important, with "non-ASCII" or 188 "internationalized" as its opposite. 190 The term "internationalized email address", or "IMA", refers to an 191 address permitted by this specification. [[anchor3: Note in Draft/ 192 Placeholder: it appears that the term "IMA" is not used in a precise 193 and consistent way across the document set. It is sometimes used to 194 refer simply to a "non-ASCII" address; sometimes to an address that 195 contains non-ASCII characters, even if that address is encoded into 196 ASCII characters (i.e., as an ACE); and sometimes as an address that 197 may contain non-ASCII characters but may also be a traditional 198 adress. The definition needs to be clarified in an upcoming draft 199 and all uses of the term brought into line with the definition.]] 201 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 202 and "MAY" in this document are to be interpreted as described in RFC 203 2119 [RFC2119]. 205 2. Overview of the Approach 207 This set of specifications changes both SMTP and the format of email 208 headers to permit non-ASCII characters to be represented directly. 209 Each important component of the work is described in a separate 210 document. The document set, whose members are described in the next 211 section, also contains informational documents whose purpose is to 212 provide operational and implementation suggestions and guidance for 213 the protocols. 215 3. Document Roadmap 217 In addition to this document, the following documents make up this 218 specification and provide advice and context for it. 220 o SMTP extensions. This document provides an SMTP extension for 221 internationalized addresses, as provided for in RFC 2821 222 [I18Nemail-SMTPext]. 223 o Email headers in UTF-8. This document essentially updates RFC 224 2822 to permit some information in email headers to be expressed 225 directly by Unicode characters encoded in UTF-8 when the SMTP 226 extension is used [I18Nemail-UTF8]. 228 o In-transit downgrading from internationalized addressing with the 229 SMTP extension and UTF-8 headers to traditional email formats and 230 characters [I18Nemail-downgrade]. Downgrading either at the point 231 of message origination or after the mail has successfully been 232 received by a final delivery SMTP server (sometimes called an 233 "MDA") involve different constraints and possibilities; see 234 Section 4.3 and Section 5, below. 235 o Operational guidelines and suggestions for the deployment of 236 internationalized email [I18Nemail-ops]. 237 o Special considerations for mailing lists and similar distributions 238 during the transition to internationalized email [I18Nemail- 239 Exploder]. 240 o Design decisions, history, and alternative models for 241 internationalized Internet email [I18Nemail-history]. 243 4. Overview of Protocol Extensions and Changes 245 4.1. SMTP Extension for Internationalized eMail Address 247 An SMTP extension, "IMA" [[anchor7: Extension name should be 248 corrected when we make a final decison and synchronized with the 249 "I18Nemail-SMTPext" document]] is specified that 250 o Permits the use of UTF-8 strings in email addresses, both local 251 parts and domain names 252 o Permits the selective use of UTF-8 strings in email headers (see 253 the next subsection) 254 o Requires that the server advertise the 8BITMIME extension 255 [RFC1652] and that the client support 8-bit transmission so that 256 header information can be transmitted without using a special 257 content-transfer-encoding. 258 o Provides information to support downgrading mechanisms. 260 Some general principles apply to this work. 261 1. Whatever encoding is used should apply to the whole address and 262 be directly compatible with software used at the user interface. 263 2. An SMTP relay must 264 * Either recognize the format explicitly, agreeing to do so via 265 an ESMTP option, 266 * Select and use an ASCII-only address, or 267 * Bounce the message so that the sender can make another plan. 268 3. In the interest of interoperability, charsets other than UTF-8 269 are prohibited. There is no practical way to identify them 270 properly with an extension similar to this without introducing 271 great complexity. 273 4.2. Transmission of Email Header in UTF-8 Encoding 275 There are many places in MUAs or in user presentation in which email 276 addresses or domain names appear. Examples include the conventional 277 From, To, or Cc header fields; Message-IDs; In-Reply-To fields that 278 may contain addresses or domain names; in message bodies; or 279 elsewhere. We must examine all of them from an internationalization 280 perspective. The user will expect to see mailbox and domain names in 281 local characters, and to see them consistently. If non-obvious 282 encodings, such as protocol-specific ACE variants, are used, the user 283 will inevitably see them, at least occasionally, rather than "native" 284 characters and will find that discomfiting or astonishing. 285 Similarly, if different codings are used for mail transport and 286 message bodies, the user is particularly likely to be surprised, if 287 only as a consequence of the long-established "things leak" 288 principle. But the only practical way to avoid these sources of 289 discomfort, in both the medium and the longer term, is to have the 290 encodings used in transport be as nearly as possible the same as the 291 encodings used in message headers and message bodies. 293 It seems clear that the point at which email local parts are 294 internationalized is the point that email headers should simply be 295 shifted to a full internationalized form, presumably using UTF-8 296 rather than ASCII as the base character set for other than protocol 297 elements such as the header field names themselves. The transition 298 to that model includes support for address, and address-related, 299 fields within the headers of legacy systems. This is done by 300 extending the encoding models of [RFC2045] and [RFC2231]. However, 301 our target should be fully internationalized headers, as discussed 302 [I18Nemail-UTF8]. 304 4.3. Downgrading Mechanism for Backward Compatibility 306 As with any use of the SMTP extension mechanism, there is always a 307 possibility of a client that requires the feature encountering a 308 server that does not. In the case of IMA, the risk should be 309 minimized by the fact that the selection of submission servers are 310 presumably under the control of the sender's client and the selection 311 of potential intermediate relays is under the control of the 312 administration of the final delivery server. 314 For those situations, there are basically two possibilities: 315 o Reject or bounce the message, requiring the sender to resubmit it 316 with traditional-format addresses and headers. 317 o Figure out a way to downgrade the envelope or message body in 318 transit. Especially when internationalized addresses are 319 involved, downgrading will require either that an all-ASCII 320 address be obtained from some source or computed. An optional 321 extension parameter is provided as a way of transmitting an 322 alternate address. Computing an all-ASCII form of a non-ASCII 323 address requires that the sender have some knowledge. This 324 knowledge is normally restricted to final delivery servers, but 325 some extensions may be feasible there too. Downgrade issues and a 326 specification are discussed in [I18Nemail-downgrade]. 328 The first of these two options, that of rejecting or returning the 329 message to the sender MAY always be chosen. 331 There is also a third case, one in which the client is I18Nemail- 332 capable, the server is not, but the message does not require the 333 extended capabilities. In other words, both the addresses in the 334 envelope and the entire set of headers of the message are entirely in 335 ASCII (perhaps including encoded-words in the headers). In that 336 case, the client SHOULD send the message whether or not the server 337 announces the IMA capability. 339 5. Downgrading Before and After SMTP Transactions 341 In addition to the in-transit downgrades discussed above, downgrading 342 may also occur before or during initial message submission or after 343 delivery to the final delivery MTA. Because these cases have a 344 different set of available information from in-transit cases, the 345 constraints and opportunities may be somewhat different too. These 346 two cases are discussed in the subsections below. 348 5.1. Downgrading Before or During Message Submission 350 Perhaps obviously, the most convenient time to convert an address or 351 message from internationalized to conventional ASCII form is at the 352 originating MUA, either before the message is sent or after the 353 internationalized form of the message is rejected or bounced by some 354 MTA in the path to the presumed destination. At that point, the user 355 has a full range of choices available, including contacting the 356 intended recipient out of band for an alternate address, consulting 357 appropriate directories, translating the message into a different 358 language, and so on. While it is natural to think of message 359 downgrading as optimally being a fully-automated process, we should 360 not underestimate the capabilities of a user of at least moderate 361 intelligence who wishes to communicate with another such user. 363 5.2. Downgrading or Other Processing After Final SMTP Delivery 365 When an email message is received by a final delivery SMTP server, it 366 is usually stored in some form. Then it is retrieved by client 367 software via some email retrieval mechanisms such as POP, IMAP or 368 others. 370 The SMTP extension described in Section 4.1 provides protection only 371 in transport. It does not prevent MUAs and email retrieval 372 mechanisms that have not been upgraded to understand 373 internationalized addresses and UTF-8 headers from accessing stored 374 internationalized emails. 376 Since the final delivery SMTP server (to be more specific, its 377 corresponding mail storage agent) cannot safely assume that agents 378 accessing email storage will be always be capable of handling the 379 extensions proposed here, it MAY either downgrade internationalized 380 emails or specially identify messages that utilize these extensions, 381 or both. If this is the case, the final delivery SMTP server MUST 382 include a mechanism preserve the original internationalized forms 383 without information loss to support access by I18Nemail-aware agents. 385 The method and format for downgrading at the final delivery SMTP 386 server is [[anchor9: will be]] discussed in [I18Nemail-imap-pop]. 388 [[anchor10: Note in draft: There are at least four cases. Both MUA 389 and IMAP/POP are compliant. Both are non compliant. And only of 390 them is compliant. Do we need to invent different methods for each 391 case?]] 393 6. Advice to Designers and Operators of Mail-receiving Systems 395 [[anchor12: Note in draft: The material that follows contains some 396 forward-looking, predictive, statements about discussions to occur 397 and documents to be written. Be sure they are true before Last 398 Call.]] 400 In addition to the protocol specification materials in this set of 401 documents, the working group has had extensive discussions about 402 operational considerations in the use of internationalized addresses. 403 Those topics include how such addresses should be chosen, how they 404 should relate to ASCII alternatives if such alternatives exist, the 405 management of mailing lists that might support and contain a mixture 406 of all-ASCII and non-ASCII addresses, and so on. Those issues are 407 discussed in [I18Nemail-ops] and [I18Nemail-Exploder]. 409 7. Internationalization Considerations 411 This entire specification addresses issues in internationalization 412 and especially the boundaries between internationalization and 413 localization and between network protocols and client/user interface 414 actions. 416 8. Additional Issues 418 This section identifies issues that are not covered as part of this 419 set of specifications, but that will need to be considered as part of 420 IMA deployment. 422 8.1. Impact on IRIs 424 The mailto: schema in IRI [RFC3987] may need to be modified when IMA 425 is standardized. 427 8.2. POP and IMAP 429 While SMTP takes care of the transportation of messages, IMAP 430 [RFC3501] and POP3 [RFC1939] are among mechanisms used to handle the 431 retrieval of mail objects from a mail store by a client. The use of 432 internationalized mail addresses or UTF-8 headers will require 433 extensions to POP and IMAP and/or modifications to the design and 434 implementation of mail stores and the mechanisms that final delivery 435 SMTP servers use to put mail into them. However, those mechanisms 436 are separate from those associated with transport across the network 437 and are not discussed in this series of documents. The general 438 issues are [[anchor17: will be]] covered in [I18Nemail-imap-pop]. 439 Some preliminary discussion appears in in Section 5.2. 441 9. IANA Considerations 443 This overview description and framework document does not contemplate 444 any IANA registrations or other actions. Some of the documents in 445 the group have their own IANA considerations sections and 446 requirements. 448 10. Security Considerations 450 Any expansion of permitted characters and encoding forms in email 451 addresses raises some risks. There have been discussions on so 452 called "IDN-spoofing" or "IDN homograph attacks". These attacks 453 allow an attacker (or "phisher") to spoof the domain or URLs of 454 businesses. The same kind of attack is also possible on the local 455 part of internationalized email addresses. It should be noted that 456 one of the proposed fixes for, e.g., URLs, does not work for email 457 local parts since they are case-sensitive. That fix involves forcing 458 all elements that are displayed to be in lower-case and normalized. 460 Since email addresses are often transcribed from business cards and 461 notes on paper, they are subject to problems arising from confusable 462 characters. These problems are somewhat reduced if the domain 463 associated with the mailbox is unambiguous and supports a relatively 464 small number of mailboxes whose names follow local system 465 conventions; they are increased with very large mail systems in which 466 users can freely select their own addresses. 468 The internationalization of email addresses and headers must not 469 leave the Internet less secure than it is that without the required 470 extensions. The requirements and mechanisms documented in this set 471 of IMA specifications do not, in general, raise any new security 472 issues other than those associated with confusable characters -- a 473 topic that is being explored thoroughly elsewhere [IDN-nextsteps]. 474 Specific issues are discussed in more detail in the other documents 475 in this set. However, in particular, caution should be taken that 476 any "downgrading" mechanism, or use of downgraded addresses, does not 477 inappropriately assume authenticated bindings between the IMA and 478 ASCII addresses. 480 In addition, email addresses are used in many contexts other than 481 sending mail, such as for identifiers under various circumstances. 482 Each of those contexts will need to be evaluated, in turn, to 483 determine whether the use of non-ASCII forms is appropriate and what 484 particular issues they raise. 486 11. Acknowledgements 488 This document, and the related ones, were originally derived from 489 drafts by John Klensin and the JET group [Klensin-emailaddr], [JET- 490 IMA]. The work drew inspiration from discussions on the "IMAA" 491 mailing list, sponsored by the Internet Mail Consortium and 492 especially from an early draft by Paul Hoffman and Adam Costello 493 [Hoffman-IMAA] that attempted to define an MUA-only solution to the 494 IMA problem. [[anchor20: Note in draft: may want to move some of this 495 to "history" or reference it]] 497 12. Change History 499 [[anchor22: Note to RFC Editor: this section to be removed prior to 500 publication]] 502 12.1. Version 00 504 This version supercedes draft-lee-jet-ima-00 and 505 draft-klensin-emailaddr-i18n-03. It represents a major rewrite and 506 change of architecture from the former and incorporates many ideas 507 and some text from the latter. 509 12.2. Version 01 511 o Some clarifications of terminology (more to follow) and general 512 editorial improvements. 513 o Upgrades to reflect discussions during IETF 64. 514 o Improved treatment of downgrading before and after message 515 transport. 517 13. References 519 13.1. Normative References 521 [ASCII] American National Standards Institute (formerly United 522 States of America Standards Institute), "USA Code for 523 Information Interchange", ANSI X3.4-1968, 1968. 525 ANSI X3.4-1968 has been replaced by newer versions with 526 slight modifications, but the 1968 version remains 527 definitive for the Internet. 529 [I18Nemail-Exploder] 530 "Placeholder: whatever we call the mailing list document", 531 2005. 533 This document is expected to be developed by the WG. The 534 date given here is purely arbitrary. 536 [I18Nemail-SMTPext] 537 Yao, J., Ed. and X. Lee, Ed., "SMTP extension for 538 internationalized email address", draft-yao-smtpext-01 539 (work in progress), January 2006. 541 [I18Nemail-UTF8] 542 Yeh, J., "Transmission of Email Headers in UTF-8 543 Encoding", draft-yeh-ima-utf8headers-00 (work in 544 progress), October 2005. 546 [I18Nemail-constraints] 547 Klensin, J., "Internationalization in Internet 548 Applications: Issues, Tradeoffs, and Email Addresses", 549 February 2006. 551 [I18Nemail-downgrade] 552 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 553 mechanism for Internationalized eMail Address (IMA)", 554 draft-yoneya-ima-downgrade-00 (work in progress), 555 October 2005. 557 [I18Nemail-ops] 558 "Placeholder: whatever we call the operations document", 559 2005. 561 This document is expected to be developed by the WG. The 562 date given here is purely arbitrary. 564 [RFC1651] Klensin, J., Freed, N., Rose, M., Stefferud, E., and E. 565 Crocker, "SMTP Service Extensions", RFC 1651, July 1994. 567 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 568 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 569 RFC 1652, July 1994. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels'", RFC 2119, March 1997. 574 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 575 April 2001. 577 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 578 "Internationalizing Domain Names in Applications (IDNA)", 579 RFC 3490, March 2003. 581 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 582 10646", STD 63, RFC 3629, November 2003. 584 13.2. Informative References 586 [Hoffman-IMAA] 587 Hoffman, P. and A. Costello, "Internationalizing Mail 588 Addresses in Applications (IMAA)", draft-hoffman-imaa-03 589 (work in progress), October 2003. 591 [I18Nemail-history] 592 Klensin, J., "Decisions and Alternatives for 593 Internationalization of Email Addresses", April 2006. 595 This document is expected to be developed by the WG. The 596 date given here is purely arbitrary. 598 [I18Nemail-imap-pop] 599 Klensin, J., "Considerations for IMAP and POP in 600 Conjunction with Email Address Internationalization", 601 draft-klensin-ima-imappop-00a (work in progress), 602 April 2006. 604 This document is expected to be developed by the WG. The 605 date given here is purely arbitrary. 607 [IDN-nextsteps] 608 Klensin, J. and P. Faltstrom, "Review and Recommendations 609 for Internationalized Domain Names (IDN)", February 2006. 611 [JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail Address 612 (IMA)", draft-lee-jet-ima-00 (work in progress), 613 June 2005. 615 [Klensin-emailaddr] 616 Klensin, J., "Internationalization of Email Addresses", 617 draft-klensin-emailaddr-i18n-03 (work in progress), 618 July 2005. 620 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 621 STD 53, RFC 1939, May 1996. 623 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 624 Extensions (MIME) Part One: Format of Internet Message 625 Bodies", RFC 2045, November 1996. 627 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 628 Part Three: Message Header Extensions for Non-ASCII Text", 629 RFC 2047, November 1996. 631 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 632 Word Extensions: Character Sets, Languages, and 633 Continuations", RFC 2231, November 1997. 635 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 636 Mechanism", RFC 2449, November 1998. 638 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 639 April 2001. 641 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 642 4rev1", RFC 3501, March 2003. 644 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 645 Identifiers (IRIs)", RFC 3987, January 2005. 647 Authors' Addresses 649 John C Klensin 650 1770 Massachusetts Ave, #322 651 Cambridge, MA 02140 652 USA 654 Phone: +1 617 491 5735 655 Email: john-ietf@jck.com 657 YangWoo Ko 658 MOCOCO, Inc. 659 996-1, 11F, Mirae Asset Venture Tower, Daechi-dong 660 Gangnam-gu, Seoul 135-280 661 Korea 663 Email: yw@mrko.pe.kr 665 Intellectual Property Statement 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org. 689 Disclaimer of Validity 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 696 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Copyright Statement 701 Copyright (C) The Internet Society (2006). This document is subject 702 to the rights, licenses and restrictions contained in BCP 78, and 703 except as set forth therein, the authors retain all their rights. 705 Acknowledgment 707 Funding for the RFC Editor function is currently provided by the 708 Internet Society.