idnits 2.17.1 draft-lee-jet-ima-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction to IMA' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 168 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([RFC3492], [RFC1869], [RFC3987], [AppendixA], [RFC2047], [RFC2449], [RFC3920], [RFC2119], [RFC3629], [RFC3454], [RFC2821], [RFC2822], [RFC3490], [RFC3491]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 48 looks like a reference -- Missing reference section? 'RFC3490' on line 234 looks like a reference -- Missing reference section? 'RFC2821' on line 228 looks like a reference -- Missing reference section? 'RFC2822' on line 230 looks like a reference -- Missing reference section? 'RFC2047' on line 223 looks like a reference -- Missing reference section? 'RFC3491' on line 237 looks like a reference -- Missing reference section? 'RFC3920' on line 245 looks like a reference -- Missing reference section? 'RFC3454' on line 232 looks like a reference -- Missing reference section? 'RFC3987' on line 247 looks like a reference -- Missing reference section? 'RFC 2449' on line 191 looks like a reference -- Missing reference section? 'RFC1869' on line 221 looks like a reference -- Missing reference section? 'RFC2449' on line 226 looks like a reference -- Missing reference section? 'RFC3492' on line 240 looks like a reference -- Missing reference section? 'RFC3629' on line 243 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jiankang Yao, Editor 3 Draft-Lee-JET-IMA-00.txt CNNIC 4 June 27, 2005 Jeff Yeh Editor 5 Expires: December 27,2005 TWNIC 7 Internationalized eMail Address (IMA) 8 < draft-lee-jet-ima-00.txt > 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-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/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft expires on December 27, 2005. 34 Abstract 36 An email address has two parts - local part and domain part - 37 separated by "@" sign. This document describes a basic solution to 38 internationalized email address (IMA) and includes some preliminary 39 survey results. The proposed solution enables SMTP servers to support 40 IMA. The solution discussed in this document is immediately 41 deployable by interested parties without affecting or breaking any 42 other existing systems. 44 Document Conventions 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 1. Introduction to IMA 51 In order to use internationalized email addresses, we need to 52 internationalize both domain part and local part of email address. 53 Domain part of email addresses had been internationalized through 54 IDNA [RFC3490]. But the local part of email address still remains as 55 non internationalized. 57 At present, the use of Internet email address is restricted to a 58 subset of 7-bit ASCII [RFC2821][RFC2822]. The MIME extensions 59 provides a mechanism for the transmission of non-ASCII data that were 60 previously unsupported in Internet mail. But it does not provide the 61 mechanism for internationalized email address. [RFC2047] defines the 62 message header extension for non ASCII 8-bit MIME messages. However, 63 it does not address the issue if email addresses include non-ASCII 64 characters. Anticipating the need to use the internationalized email 65 address, the SMTP protocol should be extended to provide the 66 transport mechanism for the internationalized email address. The 67 length restrict to the local part in the section of RFC 2822 may need 68 to be updated. 70 2. Problem statement 72 Internationalized Domain Name (IDN) was standardized 2 years ago 73 (2003) and several registries started to accept IDN registrations and 74 the name resolutions. While the take-up of IDN varies, there is a 75 strong demand for IDN in the regions where English is not their 76 native language. 78 Particularly in the CJK community, we noticed that registrants of IDN 79 often enquired about if they could use Internationalized eMail 80 Address (IMA) too. Unfortunately, while the domain name portion of 81 the Email address could use IDN standards, there are no standards to 82 internationalize the local-part (left hand side of the "@" mark). 84 On the other hand, we envisage strong demands for IMA when IDN 85 becomes popular. IMA will also promote the deployment of IDN. 87 Several solutions for IMA have been deployed, e.g.,in China (35.com, 88 zzy.cn, bizcn.com, ce.net.cn, dns.com.cn and topbiz.cn), but the lack 89 of open and interoperable standards means that users of one system 90 could not (reliably) communicate with users of another system. 91 Therefore, the Internet community would benefit from the development 92 of an open and interoperable IETF IMA standard. 94 3. Requirements 96 Any IMA solution should qualify the following requirements: 98 3.1 Short term (2-5 years) solution 100 The solution should not extend too long, so that IMA can be adopted 101 as soon as possible by interested companies. The solution also should 102 be easily deployable, so that IMA can be easily deployed by most 103 interested organizations during 2-5 years if they wish to. 105 3.2 Backward compatible with the existing standards 107 The email service is one of the most important Internet services. Any 108 updating to Internet protocols should not interfere with the 109 operation of the Internet. The IMA solution should not break the base 110 of the email service and be backward with the existing email 111 standards. 113 3.3 Internationalized solution (over localized solution) 115 The solution should be an internationalized one rather than localized 116 one. 118 4. Architecture 120 Solving the problem of IMA is not easy. We should divide it into two 121 phases. In the first phase, we consider the ACE@ACE solution, which 122 is easy to implement, backward compatible, short-term and 123 internationalized solution. In the next phase, we may consider other 124 mechanisms such as UTF-8@ACE. In the ACE@ACE solution, the local part 125 of the IMA will be converted to ASCII Compatible Encoding; IDNA 126 (RFC3490) will be applied to the domain part of the IMA. In this 127 draft, we mainly focus on the ACE@ACE solution. 129 4.1 Encoding 131 A good ACE converting algorithm should be considered according to the 132 following criteria: 133 Popularity 134 Length of the encoded name 135 Implementation easiness 136 Produce valid email address 137 Case sensitivity 138 Impact on existing protocol 140 4.2 Normalization (IMAprep) 141 There are profiles for Stringprep such as Nameprep[RFC3491] dealing 142 with the IDN preparation and Nodeprep[RFC3920] for internationalized 143 node identifiers. IMAprep is introduced to prepare the local part of 144 IMA. IMAprep is a profile of Stringprep [RFC3454]. IMAprep [Appendix 145 A] is used to process only the local part of IMA, not the whole email 146 address. In IMAprep, no normalization and no case folding are needed. 147 And there must be a prohibited list, but we will not discuss details 148 of IMAprep in this draft. 150 4.3 Mail Delivery Agent (MDA) 152 MDA is a part of mail servers, which are responsible for delivery of 153 mails to local mail spool or sending out to another mail server. 154 Usually, IMA is represented in the format of UTF-8 in a host while it 155 should be converted into ACE format while being transported over the 156 wire. There are various unofficial conventions for structured local 157 parts, like owner-listname, user+tag, sublocal.local, path!user, etc. 158 When internationalized local part being converted into ACE format, it 159 actually causes some problems. Therefore, MDA may need to convert 160 internationalized local part back to UTF8 (or original encoding) for 161 further mailing processing. 163 4.4 Prefix 165 Since the prefix "xn--" had been used for IDNA, it is better that 166 other prefix such as "bq--" is used for the local part of IMA to 167 avoid of potential confusion. 169 5. Deployment 171 Email is an important and popular internet service. Any new 172 deployments of SMTP servers which support IMA should not disturb the 173 running of current email system. Since all the SMTP servers around 174 the world can not support IMA immediately, ACE@ACE solution would be 175 the most harmless solution to implement and deploy. 177 6. Potential problems 179 6.1 Impact to IRI 180 The mailto: schema in IRI [RFC3987] may need to be modified when IMA 181 is standardlized. 183 6.2 POP and IMAP 185 While SMTP takes care of the transportation of messages and the 186 header fields correspond to the display management by the clients, 187 POP essentially handles the retrieval of mail objects from the server 188 by a client. In order to use internationalized user names based on 189 IMA for the retrieval of messages from a mail server using the POP 190 protocol, a new capability should be introduced following the POP3 191 extension mechanism [RFC 2449]. 192 IMAP uses the traditional user name which is based on ASCII. IMAP 193 should be updated to support the internationalized user names based 194 on IMA for the retrieval of messages from a mail server 196 7. Security Considerations 198 There have been discussions on so called "IDN-spoofing". IDN 199 homograph attacks allow an attacker/phisher to spoof the domain/URLs 200 of businesses. The same kind of attack is also possible on the local 201 part of internationalized email addresses. 203 IMA can also introduce new email spamming. Many local parts of IMA 204 will be the names of the person or company, which could easily be 205 used by email spammer to guess the email address to produce the 206 rubbish emails. 208 Email spamming may combine with email spoofing and homograph attacks, 209 making it more difficult to determine who actually sent the email. 211 Any solution that meets the requirements in this document must not be 212 less secure than the current Email Service. Specifying requirements 213 for internationalized email addresses does not itself raise any new 214 security issues. However, any change to the email service may affect 215 the security of any protocol that uses the email address. A thorough 216 evaluation of those protocols for security concerns will be needed 217 when they are developed. 219 8. References 221 [RFC1869] Klensin,J., Freed, N., Rose, M., Stefferud, E., Crocker, D., 222 "SMTP Service Extensions", RFC 1869, November 1995. 223 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 224 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 225 November 1996. 226 [RFC2449] R. Gellens, C. Newman, L. Lundblade, "POP3 Extension 227 Mechanism" RFC2449 November 1998 228 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 229 April 2001. 230 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 231 2001. 232 [RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized 233 Strings ("stringprep")" RFC3454 December 2002 234 [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, 235 "Internationalizing Domain Names in Applications (IDNA)",RFC 3490, 236 March 2003. 237 [RFC3491] P. Hoffman , M. Blanchet, "Nameprep: A Stringprep Profile 238 for Internationalized Domain Names" RFC3491 March 2003 240 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 241 for Internationalized Domain Names in Applications (IDNA)", RFC 3492, 242 March 2003. 243 [RFC3629] Yergeau, F.,"UTF-8, a transformation format of ISO 10646", 244 RFC 3629, November 2003. 245 [RFC3920] P. Saint-Andre, "Extensible Messaging and Presence Protocol 246 (XMPP): Core", RFC3920 October 2004 247 [RFC3987] M. Duerst, M. Suignard, "Internationalized Resource 248 Identifiers (IRIs)", RFC3987 January 2005 250 9. Authors 252 Xiaodong LEE (lee@cnnic.cn) 253 China Internet Network Information Center (CNNIC) 255 Nai-Wen Hsu (snw@twnic.net.tw) 256 Taiwan Network Information Center (TWNIC) 258 Yoshiro YONEYA yone@jprs.co.jp 259 Japan Registry Services, Co. Ltd 261 YangWoo Ko (yw@mrko.pe.kr) 262 Korea Network Information Center 264 James Seng (james@seng.cc) 265 Former co-chair of IETF IDN Working Group 267 Editors 269 Jiankang YAO (yaojk@cnnic.cn) 270 China Internet Network Information Center (CNNIC) 272 Jeff Yeh (jeff@twnic.net.tw) 273 Taiwan Network Information Center (TWNIC) 275 10. Acknowledgments 277 Authors gratefully acknowledge the contributions of: 279 * John C Klensin for his discussion with us in 62nd IETF meeting and 280 his internet draft about IMA 281 * Paul Hoffman and Adam M. Costello for their internet draft about 282 IMA 283 Appendix A: IMAprep 285 Conclusion: no normalization, but there still prep needed, define our 286 own prep for the email local part 288 our own prep: 289 no normalization 290 no case folding 291 prohibited list - ..... (discussed later after meeting ) 293 local part ??problem: 294 No RFC standards define this part 295 The MDA must support internationalized local part, anyway 296 No use of ACE deals the mail processing, so it should be 297 converted back to UTF8, then be dealt with the mail processing 298 Intellectual Property Statement 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be 307 found in BCP 78 and BCP 79. 308 Copies of IPR disclosures made to the IETF Secretariat and any 309 assurances of licenses to be made available, or the result of an 310 attempt made to obtain a general license or permission for the use of 311 such proprietary rights by implementers or users of this 312 specification can be obtained from the IETF on-line IPR repository at 313 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention 315 any copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at ietf- 318 ipr@ietf.org. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on 323 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 324 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 325 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 326 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 327 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Copyright Statement 332 Copyright (C) The Internet Society (2005). This document is 333 subject to the rights, licenses and restrictions contained in BCP 78, 334 and except as set forth therein, the authors retain all their rights.