idnits 2.17.1 draft-yao-eai-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2009) is 5315 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ASCII' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC1652' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'RFC3461' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC3463' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC3490' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC4409' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'DeploymentTests' is defined on line 291, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5336 (Obsoleted by RFC 6531) ** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533) -- No information found for draft-yao-eai-tests - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft X. Lee 4 Intended status: Informational CNNIC 5 Expires: March 12, 2010 September 8, 2009 7 Problems of impeding the use of internationalized email address 8 draft-yao-eai-problem-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on March 12, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 Many organizations have implemented and tested the internationalized 57 email systems based on the key RFCs which have been published. This 58 document points out some problems, which blocks the receiver to 59 receive the internationalized email address and may impede the 60 deployment and use of the internationalized email address. Knowing 61 the problems will help the smooth deployment of Email Address 62 Internationalization system. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Problem statment . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Initial Implementation and Test . . . . . . . . . . . . . . . . 4 71 4. Problems identified in the initial implementation and test . . 4 72 4.1. SMTP client . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4.2. Relay Server . . . . . . . . . . . . . . . . . . . . . . . 4 74 4.3. SMTP Server . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4.4. Email Filter . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.5. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4.6. Mail User Agent . . . . . . . . . . . . . . . . . . . . . . 5 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 81 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5 82 8.1. draft-yao-eai-problem: Version 00 . . . . . . . . . . . . . 6 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 88 1. Introduction 90 The IETF has published five RFCs [RFC4952] [RFC5335] [RFC5336] 91 [RFC5337] [RFC5504] about internationalized email addresses. CNNIC 92 has implemented these RFCs, does some tests and identify some 93 problems during the initial deployment. This document is mainly for 94 pointing out the problems of blocking the use of internationalized 95 email address that needs to be considered in the deployment. The 96 possible soultion to these poroblems can be found in the deployment 97 document [DeploymentGuidelines]. 99 1.1. Role of this specification 101 The framework document specifies the requirements for, and describes 102 components of, full internationalization of email address. The EAI 103 SMTP extension document [RFC5336] specifies the SMTP extension to use 104 the internationalized email address. The EAI header document 105 [RFC5335] allows the internationalized email address headers. The 106 EAI downgrade document [RFC5504] addresses how to downgrade to be 107 compatible with the current non-EAI-system. The deployment document 108 [DeploymentGuidelines] addresses the possible solution to the 109 problems identified in this document. 111 1.2. Terminology 113 All the specialized terms used in this specification are defined in 114 the framework document [RFC4952], the EAI SMTP extension document 115 [RFC5336], the EAI header document [RFC5335] and the base Internet 116 email specifications [RFC5321] [RFC5322]. In particular, the terms 117 "ASCII user", and "i18mail user" are used in this document according 118 to the definitions in the framework one. 120 [[anchor3: NOTE TO RFC EDITOR: Please remove the following text 121 before publication.]] 122 Some ideas of this specification is being discussed on the EAI 123 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 124 information about subscribing. The list's archive is at 125 http://www1.ietf.org/mail-archive/web/ima/index.html. 127 2. Problem statment 129 If the i18mail user sends the message with the internationalized 130 email address which is successfuly received by the receiver without 131 any downgrading, we define such sending as the successful sending of 132 internationalized email address. If the i18mail user sends the 133 message with the internationalized email address because the SMTP 134 client or mail user agent or submission server can not support 135 internationalized email address, refuse to send the message and 136 result into the failure of sending of internationalized email 137 address, we call it the failure operation. In other situation, we 138 call it the failure of the sending of internationalized email 139 address. In order to have more successful sending of 140 internationalized email address, less downgrade operation or failure 141 operation, we need identify the problems which block the successful 142 sending of internationalized email address. 144 3. Initial Implementation and Test 146 As far as we know, CNNIC, TWNIC, AFILIAS, JPRS and NIDA have 147 implemented the [RFC5335], [RFC5336], [RFC5504]. CNNIC updates the 148 Postfix source code to support EAI. [RFC5504]. The openweb mail is 149 used for EAI clients. Both TWNIC and AFILIAS update Sendmail. JPRS 150 uses C language to implement EAI. NIDA uses python to implement it. 151 CNNIC/TWNIC/JPRS/AFILIAS/NIDA have the co-tests based on the scenario 152 documnent. We summarize the following problems identified in our 153 tests which may block the successful sending of internationalized 154 email address. 156 4. Problems identified in the initial implementation and test 158 The key aim of EAI WG is to promote the use of internationalized 159 email address. In order to have the smooth operation of EAI system 160 and have the success use of internationalized email address, we 161 should address all the following problems before deploying the EAI 162 systems. 164 4.1. SMTP client 166 If the SMTP client or submisstion server is not ready to support 167 [RFC5335] and [RFC5336], the EAI mail user agent can not submit the 168 email message to the SMTP client. So it is impossible to receive the 169 internationalized email address from the i18mail user. 171 4.2. Relay Server 173 If the relay server has not EAI-capability, it will not accept any 174 UTF8SMTP message. Some downgrading may happen. 176 4.3. SMTP Server 178 The SMTP server gets the message from the SMTP client. If the SMTP 179 server which is the final delivery server has not EAI-capability, the 180 receiver can not get the i18n messages. 182 4.4. Email Filter 184 Many email receivers have installed the email filters. The non-EAI- 185 capability filiters may regard EAI messages as the rubbish and drop 186 them immediately. 188 4.5. Firewall 190 The traditional fireall specified in [RFC2979] will not understand 191 the keyword "UTF8SMTP", These actions will lead to unnecessary 192 message failure, and the SMTP connection will be cut off by the 193 firewall. 195 4.6. Mail User Agent 197 Most non-EAI-capability Mail User Agent (MUA) can not support 198 internationalized email address. It will regard the 199 internationalized email address as illegal and refuse to send the 200 message on behalf of the i18nmail user. 202 5. IANA Considerations 204 There is no IANA consideraton. 206 6. Security Considerations 208 See the extended security considerations discussion in the framework 209 document [RFC4952]. 211 7. Acknowledgements 213 Many ideas are from the discussion in the list ima@ietf.org. John C 214 Klensin has done a lot of reasearch on ASCII email address and 215 internationalized email address. I got many significant words or 216 ideas from him. Many friends and experts in the EAI WG help us to 217 produce the valuable ideas. Many organizations including CNNIC, 218 TWNIC, JPRS, NIDA, AND AFFLILIAS have implemented EAI systems. These 219 organizations have already done a lot of inter-operating testing. 221 8. Change History 223 [[anchor13: RFC Editor: Please remove this section.]] 225 8.1. draft-yao-eai-problem: Version 00 227 o identifying the problems during EAI implementation and initial 228 tests" 230 9. References 232 9.1. Normative References 234 [ASCII] American National Standards Institute (formerly United 235 States of America Standards Institute), "USA Code for 236 Information Interchange", ANSI X3.4-1968, 1968. 238 [DeploymentGuidelines] 239 Yao, J. and X. Lee, "Guidelines for Internationalized 240 Email Deployment", draft-yao-eai-deployment-03.txt (work 241 in progress), September 2009. 243 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 244 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 245 RFC 1652, July 1994. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 251 Firewalls", RFC 2979, October 2000. 253 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 254 Extension for Delivery Status Notifications (DSNs)", 255 RFC 3461, January 2003. 257 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 258 RFC 3463, January 2003. 260 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 261 "Internationalizing Domain Names in Applications (IDNA)", 262 RFC 3490, March 2003. 264 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 265 10646", RFC 3629, November 2003. 267 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 268 RFC 4409, April 2006. 270 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 271 Internationalized Email", RFC 4952, July 2007. 273 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 274 October 2008. 276 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 277 October 2008. 279 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 280 September 2008. 282 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 283 Email Addresses", RFC 5336, September 2008. 285 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 286 Status and Disposition Notifications", RFC 5337, 287 September 2008. 289 9.2. Informative References 291 [DeploymentTests] 292 YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test 293 and Evaulation for EAI deployment", 294 draft-yao-eai-tests-00.txt (work in progress), 295 August 2009. 297 [RFC5504] YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 298 mechanism for Internationalized eMail Address", RFC 5504, 299 3 2009. 301 Authors' Addresses 303 Jiankang YAO 304 CNNIC 305 No.4 South 4th Street, Zhongguancun 306 Beijing 308 Phone: +86 10 58813007 309 Email: yaojk@cnnic.cn 311 Xiaodong LEE 312 CNNIC 313 No.4 South 4th Street, Zhongguancun 314 Beijing 316 Phone: +86 10 58813020 317 Email: lee@cnnic.cn