idnits 2.17.1 draft-yao-eai-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The IETF key RFCs [RFC6530] [RFC6531] [RFC6532] [RFC6533] provide the basis of internationalized email addresses. internationalized email Protocols are used to exchange the message between at least two SMTPUTF8-aware SMTP servers. If only one SMTP server supports the internationalized email protocols, then internationalized email SHOULD not be used. It is not possible to support internationalized email protocol within one night. It is clear that one internationalized email user sends the message to one internationalized email user or one ASCII user. The situation is a little complex when one internationalized email user sends the multi-users who the Message Submission Agent (MSA)[RFC6409] cannot know whether the destination SMTP server can support the SMTPUTF8 ability before sending the EHLO command to the server. On the other hand, we cannot judge the SMTPUTF8 ability just according to the email address itself. Even if an destination email address is all-ASCII, it still has the possibility that the destination server is SMTPUTF8-aware. If an internationalized email user sends the message to both internationalized email users and ASCII users, a MSA can deal it with its own way based on [RFC6531]. The MSA may choose the following strategy: if all recipients are internationalized email users, it will use SMTPUTF8 ability to send the message; if one of the recipients is the ASCII user, it may choose the rejection of the message or other ways. For example, if an internationalized message is sent to 10 users one of which is an ASCII user, the MSA may have to say EHLO 10 times before deciding to reject the message. This procedure of judging whether the SMTP server is SMTPUTF8-aware is time-consuming. In order to help the internationalized email address delivery and save time, this document suggests to add the new DNS RR type for internationalized email protocols. Through this RR type, the SMTP client can know whether the destination SMTP server can support the SMTPUTF8 ability before sending the EHLO command to the server. == 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 (March 5, 2012) is 4406 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) == Missing Reference: 'RFC6409' is mentioned on line 95, but not defined == Unused Reference: 'RFC2119' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'RFC4409' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'DeploymentTests' is defined on line 225, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) -- No information found for draft-yao-eai-tests - is the name correct? Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft S. Shen 4 Intended status: Standards Track CNNIC 5 Expires: September 6, 2012 March 5, 2012 7 SMTPUTF8 Capability Indicator 8 draft-yao-eai-dns-00.txt 10 Abstract 12 Key RFCs for internationalized email addresses specify the basic 13 protocols for using them. The SMTP client can only know the SMTP 14 server's ability by EHLO command. In order to help the 15 internationalized email address delivery, this document suggests to 16 add the new DNS RR type for internationalized email protocols. 17 Through this RR type, the SMTP client can know whether the 18 destination SMTP server can support the SMTPUTF8 ability before 19 sending the EHLO command to the server. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 6, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. The SMTPUTF8 Resource Record . . . . . . . . . . . . . . . . . 3 70 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. The usage of SMTPUTF8 RR . . . . . . . . . . . . . . . . . 4 72 2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 76 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5 77 6.1. draft-yao-eai-dns: Version 00 . . . . . . . . . . . . . . . 5 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 The IETF key RFCs [RFC6530] [RFC6531] [RFC6532] [RFC6533] provide the 86 basis of internationalized email addresses. internationalized email 87 Protocols are used to exchange the message between at least two 88 SMTPUTF8-aware SMTP servers. If only one SMTP server supports the 89 internationalized email protocols, then internationalized email 90 SHOULD not be used. It is not possible to support internationalized 91 email protocol within one night. It is clear that one 92 internationalized email user sends the message to one 93 internationalized email user or one ASCII user. The situation is a 94 little complex when one internationalized email user sends the multi- 95 users who the Message Submission Agent (MSA)[RFC6409] cannot know 96 whether the destination SMTP server can support the SMTPUTF8 ability 97 before sending the EHLO command to the server. On the other hand, we 98 cannot judge the SMTPUTF8 ability just according to the email address 99 itself. Even if an destination email address is all-ASCII, it still 100 has the possibility that the destination server is SMTPUTF8-aware. 101 If an internationalized email user sends the message to both 102 internationalized email users and ASCII users, a MSA can deal it with 103 its own way based on [RFC6531]. The MSA may choose the following 104 strategy: if all recipients are internationalized email users, it 105 will use SMTPUTF8 ability to send the message; if one of the 106 recipients is the ASCII user, it may choose the rejection of the 107 message or other ways. For example, if an internationalized message 108 is sent to 10 users one of which is an ASCII user, the MSA may have 109 to say EHLO 10 times before deciding to reject the message. This 110 procedure of judging whether the SMTP server is SMTPUTF8-aware is 111 time-consuming. In order to help the internationalized email address 112 delivery and save time, this document suggests to add the new DNS RR 113 type for internationalized email protocols. Through this RR type, 114 the SMTP client can know whether the destination SMTP server can 115 support the SMTPUTF8 ability before sending the EHLO command to the 116 server. 118 1.1. Terminology 120 All the specialized terms used in this specification are defined in 121 the framework document [RFC6530], the internationalized email SMTP 122 extension document [RFC6531], the internationalized email header 123 document [RFC6532] and the base Internet email specifications 124 [RFC5321] [RFC5322], and the basic DNS protocols [RFC1035]. 126 2. The SMTPUTF8 Resource Record 127 2.1. Format 129 The SMTPUTF8 RR has mnemonic SMTPUTF8 and type code xx (decimal). It 130 is not class-sensitive. Its RDATA is comprised of a single field, 131 . The field MUST be present. The value of 132 is that domain names [RFC1035] separated by semicolon or the value is 133 "all" or "no". If the value is the domain names, it means that the 134 hosts represented by the domain names are SMTPUTF8-aware. If the 135 value is "all", it means that all the hosts pointed by the owner 136 domain name MX records are SMTPUTF8-aware. If the value is "no", it 137 means that all the hosts pointed by the owner domain name MX records 138 are not SMTPUTF8-aware. The wildcards in the SMTPUTF8 RR SHOULD NOT 139 be used. 141 SMTPUTF8 143 The SMTPUTF8 RR indicates that whether the domain represented by the 144 owner of the SMTPUTF8 RR is SMTPUTF8-aware or not. 146 2.2. The usage of SMTPUTF8 RR 148 All SMTPUTF8-aware SMTP servers should be configured with the 149 SMTPUTF8 RR. The SMTPUTF8-aware SMTP client or MSA should check the 150 SMTPUTF8 type before sending the internationalized message to the 151 multi-users. If there is no SMTPUTF8 RR configured for the specific 152 domain, the SMTP client should regard that domain as SMTPUTF8-unware. 153 If the SMTPUTF8 RR is configured for the specific domain, the SMTP 154 client should act based on the value of SMTPUTF8 RR. 156 2.3. Discussion 158 [[anchor4: This topic is for WG discussion. If a new DNS type is not 159 suggested, a TXT record with the special target value may be used. 160 (The mechanism follows the dkim example.)]] 162 3. IANA Considerations 164 The type code xx should be assigned by IANA. 166 4. Security Considerations 168 See the extended security considerations discussion in the framework 169 document [RFC6530]. 171 The administrators of email systems should configure this new DNS RR 172 type while configuring their internationalized email service. The 173 SMTP client can know the server's ability before saying EHLO. There 174 may have some mis-configurations. For example, althoug the SMTPUTF8 175 RR is not configured, but the server indeed supports the SMTPUTF8. 176 Under this situation, the client may refuse to send the 177 internationalized message. 179 5. Acknowledgements 181 Many thanks to coremail colleagues' helpful discussions. 183 6. Change History 185 [[anchor8: RFC Editor: Please remove this section.]] 187 6.1. draft-yao-eai-dns: Version 00 189 o dns lookup for eai 191 7. References 193 7.1. Normative References 195 [RFC1035] Mockapetris, P., "Domain names - implementation and 196 specification", STD 13, RFC 1035, November 1987. 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 202 RFC 4409, April 2006. 204 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 205 October 2008. 207 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 208 October 2008. 210 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 211 Internationalized Email", RFC 6530, February 2012. 213 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 214 Email", RFC 6531, February 2012. 216 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 217 Email Headers", RFC 6532, February 2012. 219 [RFC6533] Hansen, T., Newman, C., and A. Melnikov, 220 "Internationalized Delivery Status and Disposition 221 Notifications", RFC 6533, February 2012. 223 7.2. Informative References 225 [DeploymentTests] 226 YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test 227 and Evaulation for EAI deployment", 228 draft-yao-eai-tests-00.txt (work in progress), 229 August 2009. 231 Authors' Addresses 233 Jiankang YAO 234 CNNIC 235 No.4 South 4th Street, Zhongguancun 236 Beijing 238 Phone: +86 10 58813007 239 Email: yaojk@cnnic.cn 241 Shuo SHEN 242 CNNIC 243 No.4 South 4th Street, Zhongguancun 244 Beijing 246 Email: shenshuo@cnnic.cn