idnits 2.17.1 draft-ietf-eai-scenarios-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 26, 2006) is 6513 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: 'I-D.ietf-eai-framework' is defined on line 327, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-eai-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-eai-framework (ref. 'I-D.ietf-eai-framework') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Expires: December 28, 2006 June 26, 2006 6 UTF-8 Mail: Scenarios 7 draft-ietf-eai-scenarios-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes some scenarios in which one can imagine 41 internationalized email addresses deployed, and tries to draw some 42 conclusions about what's acceptable and what's not for users in those 43 scenarios. 45 One possible set of extensions that can work in these scenarios is 46 those described in the UTF8MAIL extension documents. 48 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. User interface issues . . . . . . . . . . . . . . . . . . 3 58 1.3. Ignored issues . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Important Scenarios . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Two i18mail users . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Three i18mail users . . . . . . . . . . . . . . . . . . . 5 62 2.3. i18mail mailing list . . . . . . . . . . . . . . . . . . . 5 63 2.4. One i18mail user sends to one ascii user . . . . . . . . . 5 64 2.5. An i18mail user sends to one ascii user and one 65 i18mail user . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.6. An i18mail user sends to a mailing list with a mix of 67 users . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.7. An i18mail user forwards to an ASCII user . . . . . . . . 7 69 3. Other scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Two i18mail users, intermediate non-extended MTA . . . . . 7 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Intellectual Property and Copyright Statements . . . . . . . . . . 10 78 1. Introduction 80 With the advent of internationalized email addresses [ref], there is 81 a very real risk that people using Internet email will have problems 82 communicating that they did not have before. This document tries to 83 sketch some of the scenarios, define what "proper" behaviour would be 84 in the situations, and describe how this will constrain solutions to 85 the "internationalized email" problem. 87 Because of the well known phenomenon that short documents get more 88 review, the document tries to be as brief as possible, as long as 89 that does not sacrifice clarity. 91 1.1. Terminology 93 Terminology is inherited from the UTF8SMTP framework [I-D.ietf-eai- 94 framework] - in particular, the terms "ascii address", 95 "internationalized email address" (EAI), "ascii user", "i18mail 96 user", "message" and "mailing list" are used with the definitions 97 from that document. 99 The term "UTF8SMTP" is used to refer to the particular solution 100 proposed in that framework, while "i18n mail" refers to any solution 101 that could concievably satisfy these scenarios' requirements. 103 The pronoun "he" is used to indicate a human of indeterminate sex. 105 1.2. User interface issues 107 In internationalization, one of the thornier issues has always been 108 user interfaces. In particular in this context, the ability to 109 manipulate text strings (email addresses, in this case) in a script 110 that the user does not have familiarity with is an issue. 112 A main purpose of i18mail is to allow users to avoid doing so when 113 corresponding with users in their own language locale when that 114 locale normally does not use ASCII - but unless we accept an Internet 115 email community of many small fragments, the introduction of "local" 116 characters into email addresses will cause users to be exposed to 117 addresses that they have trouble recognizing, are unable to enter, 118 and in fact may be unable to display; in some cases, even storing the 119 addresses is an issue. 121 For instance, handling of right-to-left scripts like Arabic in 122 environments used to left-to-right scripts like Thai can be a serious 123 challenge. 125 In order to keep this document short, the following capabilities are 126 assumed: 128 o An i18mail user is able to enter and display directly all 129 characters of interest to him in his language locale. 131 o An i18mail user is able to display all valid characters for EAI 132 addresses, store them in an address book, and use "reply" without 133 damaging the address. 135 o If the i18mail solution requires keeping extra information around 136 for an address in some cases, the i18mail user is capable of 137 manipulating that information, including storing that information 138 in his address book 140 One can imagine special circumstances where some of these do not 141 represent an optimal solution (for instance, a Thai user may prefer 142 to handle the ASCII address of an Arabic correspondent rather than 143 his Arabic one), but this is an added complication, and is ignored 144 for the moment. 146 1.3. Ignored issues 148 All the scenarios assume that all parties desire to communicate, that 149 spam filters do not eat messages randomly, and that the mail service 150 behaves according to specification. These are not tenable 151 assumptions in the real world, but considering them would make this 152 document much longer. 154 2. Important Scenarios 156 In the scenario descriptions below, A, B and C are i18mail users. X 157 (and Y and Z if they need to occur) are ascii users. L is an i18n- 158 aware mailing list; LA (not used yet) is a non-i18n-aware mailing 159 list. 161 Apart from the messages being exchanged, and A knowing the addresses 162 of the ones he sends mail to, which are presumed to be made known to 163 A through some other method (business cards, web pages, mail from 164 other users and directories are some examples), there is no 165 communication required between the users. 167 2.1. Two i18mail users 169 One i18mail user (A) sends a message to another i18mail user (B), and 170 desires to use his EAI address. The recipient replies to the 171 message. 173 Requirement: The message must arrive at the recipient. The reply 174 must arrive at the sender. The email addresses visible to the sender 175 and recipient must be the EAI addresses. 177 2.2. Three i18mail users 179 As above, but A sends his message to both B and C. Both reply to all 180 the recipients listed in the message. 182 Requirement: As above - B and C must get the message, A and C must 183 get the reply from B, A and B must get the reply from C. The email 184 addresses visible to A, B and C must all be the EAI addresses. 186 2.3. i18mail mailing list 188 A sends his message to L, a mailing list, which has subscribers B and 189 C. Both reply to the mailing list. The mailing list is i18n aware. 191 Requirement: As above - all messages arrive, with EAI addresses 192 preserved for all 3 users. 194 2.4. One i18mail user sends to one ascii user 196 A, an i18mail user, sends to X, an ascii user. X replies. 198 In this scenario, it is a given that A, the sender, has to have some 199 facility for handling ASCII; he has to at least be able to display 200 and enter an ASCII address. 202 Precondition: A has to have an ascii address. 204 Requirement: There must be an algorithmic series of steps that A can 205 follow in order to get a message to X, and where X's reply gets back 206 to A. 208 There is no requirement that X sees the EAI address of A, or that the 209 address of A that X sees be one that A knows about beforehand; the 210 requirement is that the messages get there. This non-requirement 211 applies to all the following cases too. 213 Examples of ways this could happen: 215 o Magic happens in the network: A's message gets converted in the 216 network to a format acceptable to X. This may require A to include 217 extra information with the message to help the conversion process 218 - and may be impossible to do for the general case. 220 o Sender selection: A's i18mail message gets bounced in the network, 221 and the reception of the error report causes A to resend the 222 message using a format acceptable to X. 224 o Conversion at destination) A's message gets accepted, and X has 225 facilities available to convert it into an acceptable form for X, 226 including deriving a valid ASCII address for A. This would require 227 knowledge of i18n at X's site, but not necessarily in X's user 228 agent. 230 This is NOT an exhaustive list, and is NOT part of the requirements 231 of the scenarios. A given protocol for i18mail will in turn impose 232 new requirements on the scenarios - for instance, if extra 233 information is included with the message, a user interface may need 234 to exist to allow the sender to manipulate this information. 236 2.5. An i18mail user sends to one ascii user and one i18mail user 238 In this scenario, A sends to B and X; both reply. 240 Precondition: A and B have to have valid ASCII addresses. 242 Requirement: Through some series of steps, A must be able to get a 243 message to both B and X; through some series of steps, B and X must 244 be able to reply to each other and to A. X must not require 245 information outside of what is included in the message to get a 246 message to B. 248 Possible non-requirements (for discussion): 250 o Maybe the messages to B and X don't need to be exactly the same. 252 o Maybe B doesn't need to see or use A's EAI address when he's 253 replying to A and X. 255 o Maybe X doesn't need to see A's address exactly the same on the 256 message from A and the reply from B. 258 2.6. An i18mail user sends to a mailing list with a mix of users 260 In this scenario, A sends to L, and L has B and X as subscribers. B 261 and X reply. 263 Requirement: Messages get there. A will not have to know anything 264 about X in order to make the messages go through. 266 Notes and non-requirements: 268 o It may be acceptable for A to have to treat L as if L was an ASCII 269 mailing list (LA) 271 o It may be acceptable for B to see A's ASCII address, not his EAI 272 address 274 o How one can transition between this and the scenario ofSection 2.3 275 is unclear. 277 2.7. An i18mail user forwards to an ASCII user 279 In this scenario, A sends to B, and B forwards the message as a MIME 280 attachment to X. 282 Precondition: B has valid ASCII addresses. 284 Requirement: The message from B to X should arrive whether or not A's 285 address is usable by X. 287 Desirable property: If A's address is downgradable, it should be 288 usable by X for generating a message. 290 3. Other scenarios 292 This section collects scenarios that have been discussed, but where 293 there is no WG consensus on whether or not they are important enough 294 to influence the design of UTF8SMTP. 296 3.1. Two i18mail users, intermediate non-extended MTA 298 In this scenario, A sends mail to B through an MTA that does not 299 support i18mail extensions. 301 Requirement: Mail arrives. 303 Desirable property: B can see A's I18mail address in his user 304 interface, and use that to reply. 306 The reason this may not be an important scenario is that due to the 307 largely end-to-end nature of SMTP, if the end users have upgraded 308 their systems, there should be very little reason to go via a non- 309 upgraded MTA. 311 4. IANA Considerations 313 This document makes no request of IANA. 315 Note to RFC Editor: this section may be removed on publication as an 316 RFC. 318 5. Security Considerations 320 Security issues are deliberately overlooked in order to reduce the 321 size of the document. 323 6. Acknowledgements 325 7. Normative References 327 [I-D.ietf-eai-framework] 328 Klensin, J. and Y. Ko, "Overview and Framework for 329 Internationalized Email", draft-ietf-eai-framework-00 330 (work in progress), May 2006. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 Author's Address 337 Harald Tveit Alvestrand 338 Google 340 Intellectual Property Statement 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 364 Disclaimer of Validity 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Copyright Statement 376 Copyright (C) The Internet Society (2006). This document is subject 377 to the rights, licenses and restrictions contained in BCP 78, and 378 except as set forth therein, the authors retain all their rights. 380 Acknowledgment 382 Funding for the RFC Editor function is currently provided by the 383 Internet Society.