idnits 2.17.1 draft-ietf-eai-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 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 827. ** 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 (June 23, 2006) is 6514 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 707, 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' == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-smtpext (ref. 'I18Nemail-SMTPext') == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-utf8headers (ref. 'I18Nemail-UTF8') == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-downgrade (ref. 'I18Nemail-downgrade') ** 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) == Outdated reference: A later version (-09) exists of draft-ietf-eai-imap-utf8-00 == Outdated reference: A later version (-03) exists of draft-ietf-eai-scenarios-00 == Outdated reference: A later version (-06) exists of draft-iab-idn-nextsteps-05 -- Obsolete informational reference (is this intentional?): RFC 2368 (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization J. Klensin 3 (EAI) 4 Internet-Draft Y. Ko 5 Expires: December 25, 2006 MOCOCO, Inc. 6 June 23, 2006 8 Overview and Framework for Internationalized Email 9 draft-ietf-eai-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 December 25, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Overview of the Approach . . . . . . . . . . . . . . . . . . . 6 60 3. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Overview of Protocol Extensions and Changes . . . . . . . . . 7 62 4.1. SMTP Extension for Internationalized eMail Address . . . . 7 63 4.2. Transmission of Email Header in UTF-8 Encoding . . . . . . 8 64 4.3. Downgrading Mechanism for Backward Compatibility . . . . . 8 65 5. Downgrading Before and After SMTP Transactions . . . . . . . . 9 66 5.1. Downgrading Before or During Message Submission . . . . . 9 67 5.2. Downgrading or Other Processing After Final SMTP 68 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Advice to Designers and Operators of Mail-receiving Systems . 10 70 7. Internationalization Considerations . . . . . . . . . . . . . 11 71 8. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Impact on IRIs . . . . . . . . . . . . . . . . . . . . . . 11 73 8.2. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. Experimental Targets . . . . . . . . . . . . . . . . . . . . . 12 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 13. Change History . . . . . . . . . . . . . . . . . . . . . . . . 13 79 13.1. draft-klensin-ima-framework: Version 00 . . . . . . . . . 14 80 13.2. draft-klensin-ima-framework: Version 01 . . . . . . . . . 14 81 13.3. draft-ietf-eai-framework: Version 00 . . . . . . . . . . . 14 82 13.4. draft-ietf-eai-framework: Version 01 . . . . . . . . . . . 14 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 87 Intellectual Property and Copyright Statements . . . . . . . . . . 19 89 1. Introduction 91 [[anchor1: NOTE IN DRAFT: The next version of this document (-01) 92 will include references that are updated as appropriate to utilize 93 the new names of documents and a list of documents that are 94 harmonized with the WG Charter. This version is transitional and 95 those reading it are asked to be tolerant of the transition.]] 97 In order to use internationalized email addresses, we need to 98 internationalize both domain part and local part of email address. 99 The domain part of email addresses is already internationalized 100 [RFC3490], while the local part is not. Without these extensions, 101 the mailbox name is restricted to a subset of 7-bit ASCII in 102 [RFC2821]. Though MIME enables the transport of non-ASCII data, it 103 does not provide a mechanism for internationalized email address. 104 [RFC2047] defines an encoding mechanism for some specific message 105 header fields to accommodate non-ASCII data. However, it does not 106 address the issue of email addresses that include non-ASCII 107 characters. Without the extensions defined here, or some equivalent 108 set, the only way to incorporate non-ASCII characters in email 109 addresses is to use RFC2047 coding to embed them in what RFC 2822 110 [RFC2822] calls the "display name" (known as a "name phrase" or by 111 other terms elsewhere) of the relevant headers. Of course, that type 112 of coding is invisible in the message envelope and would not be 113 considered by many to be part of the address at all. 115 1.1. Role of This Specification 117 This document presents the overview and framework for an approach to 118 the next stage of email internationalization. This new stage 119 requires not only internationalization of addresses and headers, but 120 also associated transport and delivery models. The history of 121 developments and design ideas leading to this specification is 122 described in [I18Nemail-history]. 124 This document describes how the various elements of email 125 internationalization fit together and provides a roadmap for 126 navigating the various documents involved. 128 1.2. Problem statement 130 [[anchor2: Note in draft: this section needs very significant 131 reworking for both content and presentation. Changed with -01c, but 132 may still not be good enough]] 134 Though domain names are already internationalized, the 135 internationalized forms are far from general adoption by ordinary 136 users. One of the reasons for this is that we do not yet have fully 137 internationalized naming schemes. Domain names are just one of the 138 various names and identifiers that are required to be 139 internationalized. 141 Email addresses are a particularly important example of where 142 internationalization of domain names alone is not sufficient. Unless 143 email addresses are presented to the user in familiar characters and 144 formats, the user's perception will not be of internationalization 145 and behavior that is culturally friendly. One thing most of us have 146 almost certainly learned from the experience with email usage is that 147 users strongly prefer email addresses that closely resemble names or 148 initials to those involving meaningless strings of letters or 149 numbers. If the names or initials of the names in the email address 150 can be expressed in the native languages and writing systems of the 151 users, the Internet will be perceived as more natural by those whose 152 native language is not written in a subset of a Roman-derived script 153 (this is the same collection of characters known as "Latin" in 154 Unicode Consortium and ISO/IEC JTC1 publications. In much of the 155 linguistic literature, the term "Latin Script" is used exclusively 156 for the characters used to write the Latin language at the time of 157 the Roman Republic, so its use for all characters constructed from 158 that base has been a source of confusion.). 160 Internationalization of email addresses is not merely a matter of 161 changing the SMTP envelope, or of modifying the From, To, and Cc 162 headers, or of permitting upgraded mail user agents (MUAs) to decode 163 a special coding and display local characters. To be perceived as 164 usable by end users, the addresses must be internationalized, and 165 handled consistently, in all of the contexts in which they occur. 166 That requirement has far-reaching implications: collections of 167 patches and workarounds are not adequate. Even if they were 168 adequate, that approach risks an assortment of implementations with 169 different sets of patches and workarounds having been applied with 170 consequent user confusion about what is actually be run and 171 supported. Instead, we need to build a fully internationalized email 172 environment, focusing on permitting efficient communication among 173 those who share a language or other community (see [I18Nemail- 174 constraints] for an extended discussion of this optimization). That, 175 in turn, implies changes to the mail header environment to permit the 176 full range of Unicode characters where that makes sense, an SMTP 177 extension to permit UTF-8 [RFC3629] mail addressing and delivery of 178 those extended headers, and (finally) a requirement for support of 179 the 8BITMIME option so that all of this can be transported through 180 the mail system without having to overcome the limitation that 181 headers do not have content-transfer-encodings. 183 1.3. Terminology 185 This document assumes a reasonable understanding of the protocols and 186 terminology of the core email standards as documented in [RFC2821] 187 and [RFC2822]. 189 Much of the description in this document depends on the abstractions 190 of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). 191 However, it is important to understand that those terms and the 192 underlying concepts postdate the design of the Internet's email 193 architecture and the "protocols on the wire" principle. That email 194 architecture, as it has evolved, and the "wire" principle have 195 prevented any strong and standardized distinctions about how MTAs and 196 MUAs interact on a given origin or destination host (or even whether 197 they are separate). 199 In this document, an address is "all-ASCII", or just an "ASCII 200 address", if every character in the address is in the ASCII character 201 repertoire [ASCII]; an address is "non-ASCII", or an "i18mail 202 address", if any character is not in the ASCII character repertoire. 203 Such addresses may be restricted in other ways, but those 204 restrictions are not relevant here. The term "all-ASCII" is also 205 applied to other protocol elements when the distinction is important, 206 with "non-ASCII" or "internationalized" as its opposite. 208 The umbrella term to describe the email address internationalization 209 specified by this document and its companion documents is "UTF8SMTP". 210 [[anchor4: This term will be verified by further WG discussions.]] 211 For example, an address permitted by this specification is referred 212 as a "UTF8SMTP (compliant) address". 214 [[anchor5: Terminology from "scenarios" follows]] An "ASCII user" (i) 215 uses only email addresses that contain ASCII characters only, and 216 (ii) cannot generate recipient addresses that contain non-ASCII 217 characters. 219 An "i18mail user" has one or more i18mail addresses. He may have 220 ascii addresses too; if he has more than one email address, he has 221 some method to choose which address to use on outgoing email. Note 222 that under this definition, it is not possible to tell from the 223 address that an email sender or recipient is an i18mail user. 224 [[anchor6: This may need to be changed, consist with text in 225 "scenarios"]] 227 A "message" is sent from one user (sender) using a particular email 228 address to one or more other recipient email addresses (often 229 referred to just as "users" or "recipient users"). 231 A "mailing list" is a mechanism whereby a message may be distributed 232 to multiple recipients by sending to one recipient address. An agent 233 (typically not a human being) at that single address then causes the 234 message to be redistributed to the target recipients. [[anchor7: The 235 original language here ("...an user can cause...") is wrong since it 236 implies user intention. And "not under control of" is also usually, 237 but not always, true. While those conditions will often be the case, 238 a user generally don't know if a recipient address is a list or not. 239 VRFY and EXPN were designed to let would-be senders find out, but 240 they are operationally moribund. We should be sure that, if 2821 has 241 a definition for "mailing list", it is consistent (and, if it 242 doesn't, get a consistent definition intov 2821bis).]] 244 The pronoun "he" is used to indicate a human of indeterminate gender. 246 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 247 and "MAY" in this document are to be interpreted as described in RFC 248 2119 [RFC2119]. 250 2. Overview of the Approach 252 This set of specifications changes both SMTP and the format of email 253 headers to permit non-ASCII characters to be represented directly. 254 Each important component of the work is described in a separate 255 document. The document set, whose members are described in the next 256 section, also contains informational documents whose purpose is to 257 provide operational and implementation suggestions and guidance for 258 the protocols. 260 3. Document Roadmap 262 In addition to this document, the following documents make up this 263 specification and provide advice and context for it. 265 o SMTP extensions. This document provides an SMTP extension for 266 internationalized addresses, as provided for in RFC 2821 267 [I18Nemail-SMTPext]. 268 o Email headers in UTF-8. This document essentially updates RFC 269 2822 to permit some information in email headers to be expressed 270 directly by Unicode characters encoded in UTF-8 when the SMTP 271 extension is used [I18Nemail-UTF8]. 272 o In-transit downgrading from internationalized addressing with the 273 SMTP extension and UTF-8 headers to traditional email formats and 274 characters [I18Nemail-downgrade]. Downgrading either at the point 275 of message origination or after the mail has successfully been 276 received by a final delivery SMTP server (sometimes called an 277 "MDA") involve different constraints and possibilities; see 278 Section 4.3 and Section 5, below. 279 o Extensions to the IMAP protocol to support internationalized 280 headers [I18Nemail-imap]. 281 o Parallel extensions to the POP protocol [I18Nemail-pop]. 282 o Scenarios for the use of these protocols [I18Nemail-scenarios]. 283 o Special considerations for mailing lists and similar distributions 284 during the transition to internationalized email [I18Nemail- 285 Exploder]. 286 o Design decisions, history, and alternative models for 287 internationalized Internet email [I18Nemail-history]. This 288 document is not expected to be a WG product 290 4. Overview of Protocol Extensions and Changes 292 4.1. SMTP Extension for Internationalized eMail Address 294 An SMTP extension, "Email18N" [[anchor11: Extension name should be 295 corrected when we make a final decision and synchronized with the 296 "I18Nemail-SMTPext" document]] is specified that 297 o Permits the use of UTF-8 strings in email addresses, both local 298 parts and domain names 299 o Permits the selective use of UTF-8 strings in email headers (see 300 the next subsection) 301 o Requires that the server advertise the 8BITMIME extension 302 [RFC1652] and that the client support 8-bit transmission so that 303 header information can be transmitted without using a special 304 content-transfer-encoding. 305 o Provides information to support downgrading mechanisms. 307 Some general principles apply to this work. 308 1. Whatever encoding is used should apply to the whole address and 309 be directly compatible with software used at the user interface. 310 2. An SMTP relay must 311 * Either recognize the format explicitly, agreeing to do so via 312 an ESMTP option, 313 * Select and use an ASCII-only address, or 314 * Bounce the message so that the sender can make another plan. 316 If the message cannot be forwarded because the next-hop system 317 cannot accept the extension and insufficient information is 318 available to reliably downgrade it, it MUST be bounced. 319 3. In the interest of interoperability, charsets other than UTF-8 320 are prohibited. There is no practical way to identify them 321 properly with an extension similar to this without introducing 322 great complexity. 324 Conformance to the group of standards specified here for email 325 transport and delivery requires implementation of the SMTP Extension 326 specification, including recognition of the keywords associated with 327 alternate and synthesized addresses, and the UTF-8 Header 328 specification. Support for downgrading is not required, but, if 329 implemented, MUST be implemented as specified. 331 4.2. Transmission of Email Header in UTF-8 Encoding 333 There are many places in MUAs or in user presentation in which email 334 addresses or domain names appear. Examples include the conventional 335 From, To, or Cc header fields; Message-IDs; In-Reply-To fields that 336 may contain addresses or domain names; in message bodies; or 337 elsewhere. We must examine all of them from an internationalization 338 perspective. The user will expect to see mailbox and domain names in 339 local characters, and to see them consistently. If non-obvious 340 encodings, such as protocol-specific ACE variants, are used, the user 341 will inevitably see them, at least occasionally, rather than "native" 342 characters and will find that discomfiting or astonishing. 343 Similarly, if different codings are used for mail transport and 344 message bodies, the user is particularly likely to be surprised, if 345 only as a consequence of the long-established "things leak" 346 principle. But the only practical way to avoid these sources of 347 discomfort, in both the medium and the longer term, is to have the 348 encodings used in transport be as nearly as possible the same as the 349 encodings used in message headers and message bodies. 351 It seems clear that the point at which email local parts are 352 internationalized is the point that email headers should simply be 353 shifted to a full internationalized form, presumably using UTF-8 354 rather than ASCII as the base character set for other than protocol 355 elements such as the header field names themselves. The transition 356 to that model includes support for address, and address-related, 357 fields within the headers of legacy systems. This is done by 358 extending the encoding models of [RFC2045] and [RFC2231]. However, 359 our target should be fully internationalized headers, as discussed 360 [I18Nemail-UTF8]. 362 4.3. Downgrading Mechanism for Backward Compatibility 364 As with any use of the SMTP extension mechanism, there is always a 365 possibility of a client that requires the feature encountering a 366 server that does not. In the case of email address and header 367 internationalization, the risk should be minimized by the fact that 368 the selection of submission servers are presumably under the control 369 of the sender's client and the selection of potential intermediate 370 relays is under the control of the administration of the final 371 delivery server. 373 For those situations, there are basically two possibilities: 374 o Reject or bounce the message, requiring the sender to resubmit it 375 with traditional-format addresses and headers. 376 o Figure out a way to downgrade the envelope or message body in 377 transit. Especially when internationalized addresses are 378 involved, downgrading will require either that an all-ASCII 379 address be obtained from some source or computed. An optional 380 extension parameter is provided as a way of transmitting an 381 alternate address. Computing an all-ASCII form of a non-ASCII 382 address requires that the sender have some knowledge. This 383 knowledge is normally restricted to final delivery servers, but 384 some extensions may be feasible there too. Downgrade issues and a 385 specification are discussed in [I18Nemail-downgrade]. 387 The first of these two options, that of rejecting or returning the 388 message to the sender MAY always be chosen. 390 There is also a third case, one in which the client is I18Nemail- 391 capable, the server is not, but the message does not require the 392 extended capabilities. In other words, both the addresses in the 393 envelope and the entire set of headers of the message are entirely in 394 ASCII (perhaps including encoded-words in the headers). In that 395 case, the client SHOULD send the message whether or not the server 396 announces the capability specified here. 398 5. Downgrading Before and After SMTP Transactions 400 In addition to the in-transit downgrades discussed above, downgrading 401 may also occur before or during initial message submission or after 402 delivery to the final delivery MTA. Because these cases have a 403 different set of available information from in-transit cases, the 404 constraints and opportunities may be somewhat different too. These 405 two cases are discussed in the subsections below. 407 5.1. Downgrading Before or During Message Submission 409 Perhaps obviously, the most convenient time to convert an address or 410 message from internationalized to conventional ASCII form is at the 411 originating MUA, either before the message is sent or after the 412 internationalized form of the message is rejected or bounced by some 413 MTA in the path to the presumed destination. At that point, the user 414 has a full range of choices available, including contacting the 415 intended recipient out of band for an alternate address, consulting 416 appropriate directories, arranging for translation of both addresses 417 and message content into a different language, and so on. While it 418 is natural to think of message downgrading as optimally being a 419 fully-automated process, we should not underestimate the capabilities 420 of a user of at least moderate intelligence who wishes to communicate 421 with another such user. 423 In this context, one can easily imagine modifications to message 424 submission servers (as described in RFC 4409 [RFC4409]) so that they 425 would perform downgrading, or perhaps even upgrading, operations, 426 receiving messages with one or more of the internationalization 427 extensions discussed here and adapting the outgoing message, as 428 needed, to respond to the delivery or next-hop environment it 429 encounters. 431 5.2. Downgrading or Other Processing After Final SMTP Delivery 433 When an email message is received by a final delivery SMTP server, it 434 is usually stored in some form. Then it is retrieved by client 435 software via some email retrieval mechanisms such as POP, IMAP or 436 others. 438 The SMTP extension described in Section 4.1 provides protection only 439 in transport. It does not prevent MUAs and email retrieval 440 mechanisms that have not been upgraded to understand 441 internationalized addresses and UTF-8 headers from accessing stored 442 internationalized emails. 444 Since the final delivery SMTP server (to be more specific, its 445 corresponding mail storage agent) cannot safely assume that agents 446 accessing email storage will be always be capable of handling the 447 extensions proposed here, it MAY either downgrade internationalized 448 emails or specially identify messages that utilize these extensions, 449 or both. If this is the case, the final delivery SMTP server MUST 450 include a mechanism to preserve the original internationalized forms 451 without information loss to support access by I18Nemail-aware agents. 453 The method and format for downgrading at the final delivery SMTP 454 server is [[anchor13: will be]] discussed in [I18Nemail-pop] and 455 [I18Nemail-imap]. 457 [[anchor14: Note in draft: There are at least four cases. Both MUA 458 and IMAP/POP are compliant. Both are non compliant. And only of 459 them is compliant. Do we need to invent different methods for each 460 case?]] 462 6. Advice to Designers and Operators of Mail-receiving Systems 464 [[anchor16: Note in draft: The material that follows contains some 465 forward-looking, predictive, statements about discussions to occur 466 and documents to be written. Be sure they are true before Last 467 Call.]] 469 In addition to the protocol specification materials in this set of 470 documents, the working group has had extensive discussions about 471 operational considerations in the use of internationalized addresses. 472 Those topics include how such addresses should be chosen, how they 473 should relate to ASCII alternatives if such alternatives exist, the 474 management of mailing lists that might support and contain a mixture 475 of all-ASCII and non-ASCII addresses, and so on. Those issues are 476 discussed in [I18Nemail-Exploder]. 478 7. Internationalization Considerations 480 This entire specification addresses issues in internationalization 481 and especially the boundaries between internationalization and 482 localization and between network protocols and client/user interface 483 actions. 485 8. Additional Issues 487 This section identifies issues that are not covered as part of this 488 set of specifications, but that will need to be considered as part of 489 deployment of email address and header internationalization. 491 8.1. Impact on IRIs 493 The mailto: schema defined in [RFC2368] and discussed in IRI 494 [RFC3987] may need to be modified when this work is completed and 495 standardized. 497 8.2. POP and IMAP 499 While SMTP takes care of the transportation of messages, IMAP 500 [RFC3501] and POP3 [RFC1939] are among mechanisms used to handle the 501 retrieval of mail objects from a mail store by a client. The use of 502 internationalized mail addresses or UTF-8 headers will require 503 extensions to POP and IMAP and/or modifications to the design and 504 implementation of mail stores and the mechanisms that final delivery 505 SMTP servers use to put mail into them. However, those mechanisms 506 are separate from those associated with transport across the network 507 and are discussed only minimally in this series of documents. The 508 general issues, and proposed required modifications to the protocols, 509 are [[anchor21: will be]] covered in [I18Nemail-pop] and [I18Nemail- 510 imap]. Some preliminary discussion appears in in Section 5.2. 511 Implementation of internationalized POP and IMAP support is, of 512 course, not required for implementation of the transport and in- 513 transit header extensions specified in other documents or this set 514 (or vica versa). 516 9. Experimental Targets 518 In addition to the simple question of whether the model outlined here 519 can be made to work in a satisfactory way for upgraded systems and 520 provide adequate protection for un-upgraded ones, we expect that 521 actually working with the systems will provide answers to two 522 additional questions: what restrictions such as character lists or 523 normalization should be placed, if any, on the characters that are 524 permitted to be used in address local-parts and how useful, in 525 practice, will downgrading turn out to be given whatever restrictions 526 and constraints that must be placed upon it. 528 10. IANA Considerations 530 This overview description and framework document does not contemplate 531 any IANA registrations or other actions. Some of the documents in 532 the group have their own IANA considerations sections and 533 requirements. 535 11. Security Considerations 537 Any expansion of permitted characters and encoding forms in email 538 addresses raises some risks. There have been discussions on so 539 called "IDN-spoofing" or "IDN homograph attacks". These attacks 540 allow an attacker (or "phisher") to spoof the domain or URLs of 541 businesses. The same kind of attack is also possible on the local 542 part of internationalized email addresses. It should be noted that 543 one of the proposed fixes for, e.g., URLs, does not work for email 544 local parts since they are case-sensitive. That fix involves forcing 545 all elements that are displayed to be in lower-case and normalized. 547 Since email addresses are often transcribed from business cards and 548 notes on paper, they are subject to problems arising from confusable 549 characters. These problems are somewhat reduced if the domain 550 associated with the mailbox is unambiguous and supports a relatively 551 small number of mailboxes whose names follow local system 552 conventions; they are increased with very large mail systems in which 553 users can freely select their own addresses. 555 The internationalization of email addresses and headers must not 556 leave the Internet less secure than it is that without the required 557 extensions. The requirements and mechanisms documented in this set 558 of specifications do not, in general, raise any new security issues. 559 They do require a review of issues associated with confusable 560 characters -- a topic that is being explored thoroughly elsewhere 561 [IDN-nextsteps] -- and, potentially, some issues with UTF-8 562 canonicalization, discussed in [RFC3629]. The latter is also part of 563 the subject of ongoing work discussed in [Net-Unicode]. Specific 564 issues are discussed in more detail in the other documents in this 565 set. However, in particular, caution should be taken that any 566 "downgrading" mechanism, or use of downgraded addresses, does not 567 inappropriately assume authenticated bindings between the 568 internationalized and ASCII addresses. 570 In addition, email addresses are used in many contexts other than 571 sending mail, such as for identifiers under various circumstances. 572 Each of those contexts will need to be evaluated, in turn, to 573 determine whether the use of non-ASCII forms is appropriate and what 574 particular issues they raise. 576 This work will clearly impact any systems or mechanisms that is 577 dependent on digital signatures or similar integrity protection for 578 mail headers. Conventional uses of PGP and S/MIME are not affected 579 since they are used to sign body parts but not headers. On the other 580 hand, the developing work in DKIM will eventually need to consider 581 this work and vice versa: while this experiment does not propose to 582 address or solve the issues raised by DKIM and other signed header 583 mechanisms, the issues will have to be coordinated and resolved 584 eventually. 586 12. Acknowledgements 588 This document, and the related ones, were originally derived from 589 drafts by John Klensin and the JET group [Klensin-emailaddr], [JET- 590 IMA]. The work drew inspiration from discussions on the "IMAA" 591 mailing list, sponsored by the Internet Mail Consortium and 592 especially from an early draft by Paul Hoffman and Adam Costello 593 [Hoffman-IMAA] that attempted to define an MUA-only solution to the 594 address internationalization problem. [[anchor25: Note in draft: may 595 want to move some of this to "history" or reference it]] 597 13. Change History 599 [[anchor27: This section to be restructured prior to publication. It 600 may be useful to retain parts of it to facilitate establishing dates 601 and documents for the history of this work.]] 603 This document has evolved through several titles as well as the usual 604 version numbers. The list below tries to trace that thread as well 605 as changes within the substance of the document. The first document 606 of the series was posted as draft-klensin-emailaddr-i18n-00.txt in 607 October 2003. 609 13.1. draft-klensin-ima-framework: Version 00 611 This version supercedes draft-lee-jet-ima-00 and 612 draft-klensin-emailaddr-i18n-03. It represents a major rewrite and 613 change of architecture from the former and incorporates many ideas 614 and some text from the latter. 616 13.2. draft-klensin-ima-framework: Version 01 618 o Some clarifications of terminology (more to follow) and general 619 editorial improvements. 620 o Upgrades to reflect discussions during IETF 64. 621 o Improved treatment of downgrading before and after message 622 transport. 624 13.3. draft-ietf-eai-framework: Version 00 626 This version supercedes draft-klensin-ima-framework-01; its file name 627 should represent the form to be used until the IETF email address and 628 header internationalization ("EAI") work concludes. 630 o Changed "display name" terminology to be consistent with RFC 2822. 631 Also clarified some other terminology issues. 632 o Added a comment about the possible role of MessageSubmission 633 servers in downgrading. 634 o Removed the "IMA" terminology, converting it to either "EAI" or 635 prose. 636 o Per meeting and mailing list discussion, added conformance 637 statements about bouncing if neither forwarding nor downgrading 638 were possible and about implementation requirements. 639 o Updated several references. Some documents are still tentative. 640 o Fixed many typographical errors. 642 13.4. draft-ietf-eai-framework: Version 01 644 o Added comments about PGP, S/MIME, and DKIM to Security 645 Considerations 646 o Rationalized terminology and included terminology from scenarios 647 document. 649 14. References 650 14.1. Normative References 652 [ASCII] American National Standards Institute (formerly United 653 States of America Standards Institute), "USA Code for 654 Information Interchange", ANSI X3.4-1968, 1968. 656 ANSI X3.4-1968 has been replaced by newer versions with 657 slight modifications, but the 1968 version remains 658 definitive for the Internet. 660 [I18Nemail-Exploder] 661 Chung, E., "Mailing lists and internationalized email 662 addresses", June 2006. 664 Forthcoming 666 [I18Nemail-SMTPext] 667 Yao, J., Ed. and X. Lee, Ed., "SMTP extension for 668 internationalized email address", 669 draft-ietf-eai-smtpext-00 (work in progress), 670 January 2006. 672 [I18Nemail-UTF8] 673 Yeh, J., "Transmission of Email Headers in UTF-8 674 Encoding", draft-ietf-eai-utf8headers-00.txt (work in 675 progress), June 2006. 677 [I18Nemail-downgrade] 678 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 679 mechanism for Internationalized eMail Address (IMA)", 680 draft-ietf-eai-downgrade-00 (work in progress), 681 October 2005. 683 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 684 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 685 RFC 1652, July 1994. 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels'", RFC 2119, March 1997. 690 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 691 April 2001. 693 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 694 "Internationalizing Domain Names in Applications (IDNA)", 695 RFC 3490, March 2003. 697 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 698 10646", STD 63, RFC 3629, November 2003. 700 14.2. Informative References 702 [Hoffman-IMAA] 703 Hoffman, P. and A. Costello, "Internationalizing Mail 704 Addresses in Applications (IMAA)", draft-hoffman-imaa-03 705 (work in progress), October 2003. 707 [I18Nemail-constraints] 708 Klensin, J., "Internationalization in Internet 709 Applications: Issues, Tradeoffs, and Email Addresses", 710 February 2006. 712 [I18Nemail-history] 713 Klensin, J., "Decisions and Alternatives for 714 Internationalization of Email Addresses", April 2006. 716 This document is expected to be developed separately from 717 the WG. The date given here is purely arbitrary. 719 [I18Nemail-imap] 720 Resnick, P. and C. Newman, "Considerations for IMAP in 721 Conjunction with Email Address Internationalization", 722 draft-ietf-eai-imap-utf8-00 (work in progress), May 2006. 724 [I18Nemail-pop] 725 Newman, C., "POP3 Support for UTF-8", February 2006, . 729 The next version of this document will appear as 730 draft-ietf-eai-pop-00.txt. 732 [I18Nemail-scenarios] 733 Alvestrand, H., "Internationalized Email Addresses: 734 Scenarios", draft-ietf-eai-scenarios-00 (work in 735 progress), May 2006. 737 [IDN-nextsteps] 738 Klensin, J. and P. Faltstrom, "Review and Recommendations 739 for Internationalized Domain Names (IDN)", April 2006, . 743 [JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail Address 744 (IMA)", draft-lee-jet-ima-00 (work in progress), 745 June 2005. 747 [Klensin-emailaddr] 748 Klensin, J., "Internationalization of Email Addresses", 749 draft-klensin-emailaddr-i18n-03 (work in progress), 750 July 2005. 752 [Net-Unicode] 753 Klensin, J. and M. Padlipsky, "Unicode Format for Network 754 Interchange", April 2006, . 757 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 758 STD 53, RFC 1939, May 1996. 760 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 761 Extensions (MIME) Part One: Format of Internet Message 762 Bodies", RFC 2045, November 1996. 764 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 765 Part Three: Message Header Extensions for Non-ASCII Text", 766 RFC 2047, November 1996. 768 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 769 Word Extensions: Character Sets, Languages, and 770 Continuations", RFC 2231, November 1997. 772 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 773 URL scheme", RFC 2368, July 1998. 775 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 776 April 2001. 778 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 779 4rev1", RFC 3501, March 2003. 781 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 782 Identifiers (IRIs)", RFC 3987, January 2005. 784 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 785 RFC 4409, April 2006. 787 Authors' Addresses 789 John C Klensin 790 1770 Massachusetts Ave, #322 791 Cambridge, MA 02140 792 USA 794 Phone: +1 617 491 5735 795 Email: john-ietf@jck.com 797 YangWoo Ko 798 MOCOCO, Inc. 799 996-1, 11F, Mirae Asset Venture Tower, Daechi-dong 800 Gangnam-gu, Seoul 135-280 801 Korea 803 Email: yw@mrko.pe.kr 805 Intellectual Property Statement 807 The IETF takes no position regarding the validity or scope of any 808 Intellectual Property Rights or other rights that might be claimed to 809 pertain to the implementation or use of the technology described in 810 this document or the extent to which any license under such rights 811 might or might not be available; nor does it represent that it has 812 made any independent effort to identify any such rights. Information 813 on the procedures with respect to rights in RFC documents can be 814 found in BCP 78 and BCP 79. 816 Copies of IPR disclosures made to the IETF Secretariat and any 817 assurances of licenses to be made available, or the result of an 818 attempt made to obtain a general license or permission for the use of 819 such proprietary rights by implementers or users of this 820 specification can be obtained from the IETF on-line IPR repository at 821 http://www.ietf.org/ipr. 823 The IETF invites any interested party to bring to its attention any 824 copyrights, patents or patent applications, or other proprietary 825 rights that may cover technology that may be required to implement 826 this standard. Please address the information to the IETF at 827 ietf-ipr@ietf.org. 829 Disclaimer of Validity 831 This document and the information contained herein are provided on an 832 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 833 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 834 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 835 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 836 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 837 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 839 Copyright Statement 841 Copyright (C) The Internet Society (2006). This document is subject 842 to the rights, licenses and restrictions contained in BCP 78, and 843 except as set forth therein, the authors retain all their rights. 845 Acknowledgment 847 Funding for the RFC Editor function is currently provided by the 848 Internet Society.