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