idnits 2.17.00 (12 Aug 2021) /tmp/idnits32070/draft-ietf-yam-5321bis-smtp-pre-evaluation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 == 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: Small Editorial Errors: Clear up various small editorial errors, e.g., the use of "SHOULD not" in one location. YAM issue tracker issues 5, 6, 9, 12, and 13 refer to issues of this sort. The working group will add others that may be identified in its detailed review. -- The document date (January 21, 2010) is 4502 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 1869 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 YAM Working Group J. Klensin 3 Internet-Draft 4 Intended status: Informational B. Leiba 5 Expires: July 25, 2010 Huawei Technologies 6 January 21, 2010 8 Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP), 9 for advancement from Draft Standard to Full Standard by the YAM Working 10 Group 11 draft-ietf-yam-5321bis-smtp-pre-evaluation-02.txt 13 Abstract 15 This memo is a preliminary evaluation of RFC 5321, Simple Mail 16 Transfer Protocol for advancement from Draft to Full Standard. It 17 has been prepared by the The Yet Another Mail Working Group. 19 THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS 20 WRITTEN TO FACILITATE DISCUSSION WITH THE IESG. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on July 25, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . . 3 64 2. Preliminary Evaluation . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Document . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Time in Place . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.3. Implementation and Operational Experience . . . . . . . . . 3 68 2.4. Proposed Changes . . . . . . . . . . . . . . . . . . . . . 4 69 2.5. Non-Changes . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Downward references . . . . . . . . . . . . . . . . . . . . 6 71 2.7. IESG Feedback . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 79 A.1. Changes from version -01 to -02 . . . . . . . . . . . . . . 7 80 A.2. Changes from version -00 to -01 . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 A preliminary evaluation has been made of Simple Mail Tranfer 86 Protocol [RFC5321] by the Yet Another Mail (YAM) Working Group for 87 advancing it from Draft to Full Standard. The YAM WG requests 88 feedback from the IESG on this decision. 90 1.1. Note to RFC Editor 92 This Internet-Draft is not meant to be published as an RFC. It is 93 written to facilitate processing within the IESG. 95 2. Preliminary Evaluation 97 2.1. Document 99 Title: Simple Mail Transfer Protocol 101 Link: http://tools.ietf.org/html/rfc5321 103 2.2. Time in Place 105 RFC2026: _"A specification shall remain at the Draft Standard level 106 for at least four (4) months, or until at least one IETF meeting 107 has occurred."_ 109 Published: October 2008 111 2.3. Implementation and Operational Experience 113 RFC2026: _"significant implementation and successful operational 114 experience ... characterized by a high degree of technical 115 maturity and by a generally held belief that the specified 116 protocol or service provides significant benefit to the Internet 117 community."_ 119 Confidence level: Very high. 121 Electronic mail (historically known as "netmail" before "email" came 122 into common use) has been in active use in the Internet community 123 since the early 1970s. Although many small adjustments and 124 clarifications have been made, the basic transport protocol that is 125 now used has been changed in only two important ways since the 126 publication of RFC 821 in August 1982. One of those changes was the 127 introduction of DNS-based mail routing with the MX record with RFC 128 974 in January 1986 (with some small clarifications in RFC 1123 in 129 October 1979). The second was the introduction of a model for 130 negotiating optional services with RFC 1425 in February 1993. 132 While many mail systems over the years have relied more on the 133 robustness of receiving systems in the face of deviations (or 134 creative interpretations of RFC 821 language in spite of changes and 135 clarifications over the last 27 years), the DRUMS WG work that 136 produced RFC 2821 [RFC2821] in April 2001 was largely an update to 137 clarify various provisions. With the exception of a very few edge- 138 case clarifications and changes in requirements levels, systems that 139 conform to the combination of RFC 821 [RFC0821] and RFC 1869 140 [RFC1869] (both Full Standards) conform to RFC 5321. Those 141 differences represented existing practice when RFC 5321 was written 142 and have been well-tested and widely deployed. 144 2.4. Proposed Changes 146 The YAM WG proposes making the following changes in a revision: 148 Terminology: There has been ongoing controversy about the 149 terminology in RFC 5321 and especially changes made between 821 150 and 2821 or between 2821 and 5321. While we assume that 5321 is 151 adequate, the WG will review terminology as appropriate and may 152 make some adjustments. 154 Metalanguage: During and after IETF Last Call on 5321, some 155 suggestions were made about how to make metalanguage productions 156 easier to find and connect. A complete rewrite or restructuring 157 of the metalanguage should be avoided on the grounds that it would 158 carry a very high risk of introducing errors. Instead, resources 159 and tools permitting (significant manual work is now required), 160 the revised document will contain an index to productions and 161 where they are defined. 163 Normative References: RFC 5321 is worded in a way that makes some 164 references normative that are not strictly required to be. The WG 165 will consider whether those rewordings are appropriate. In 166 particular, the reference to RFC 821 will be moved to Informative 167 because all normative uses have been removed. 169 Existing Errata Reports: The working group will incorporate 170 corrections to accepted errata, as shown in the RFC Editor's 171 errata tool. Errata ID 1683 is currently the only such item. IDs 172 1543 and 1851 are reported, but unverified; the working group will 173 consider those. 175 Small Editorial Errors: Clear up various small editorial errors, 176 e.g., the use of "SHOULD not" in one location. YAM issue tracker 177 issues 5, 6, 9, 12, and 13 refer to issues of this sort. The 178 working group will add others that may be identified in its 179 detailed review. 181 Clarifications: The working group will attempt to address things 182 that have ben identified as unclear in RFC 5321. YAM issue 183 tracker issues 7, 8, 10, and 11 refer to issues of this sort. 184 There has been discussion of these on the mailing list, and the 185 resolutions of each may or may not result in a change in the 186 document. In no case will clarification changes be significant 187 enough to violate "Non-Changes", Section 2.5. 189 2.5. Non-Changes 191 The YAM WG discussed and chose not to make the following changes: 193 1. Complete revision, rearrangement, or reformatting of metalanguage 194 (see #2 above). 196 2. Any extensions that would violate the rules for Full Standard or 197 otherwise require revisiting the approved interoperability report 198 for RFC 5321. 200 3. A number of extensions and changes that would have imposed 201 significant new requirements on SMTP, or that would have implied 202 incompatible changes, were proposed during both the DRUMS WG 203 period and during the discussions that led to RFC 5321. In each 204 case, the authors were advised to prepare a specific Internet- 205 Draft describing the change, convince the community to progress 206 it to Proposed Standard, and then implement and deploy the change 207 quickly enough to "catch up" with the progress that started with 208 RFC 2821. The notion was that those changes could then be 209 integrated with the progression at the same maturity level. It 210 is important to note that, independent of any constraints imposed 211 by the YAM charter design, none of those proposals have appeared 212 and been progressed even to IETF Last Call. 214 4. As agreed when RFC 5321 was reviewed, the examples will not be 215 revised to bring them into alignment with RFC 2606 (BCP 32) 216 conventions (example.com, etc.). The issues are explained in 217 Section 1.3 of RFC 5321. The community also noted at the time 218 that the relevant examples have been in use, substantially 219 unchanged, for more than a quarter-century with no serious claims 220 of confusion or other harm being caused. 222 5. The Security Considerations section was extensively reviewed last 223 year (during the review and approval of RFC 5321). No evidence 224 has appeared since then that would require further review or 225 additional changes. 227 2.6. Downward references 229 At Full Standard, the following references would be downward 230 references: 232 RFC 5322 if 5322bis is not progressed simultaneously with 5321bis. 233 (This is not expected to happen.) 235 RFC 4291, IP Version 6 Addressing Architecture. 237 RFC 3848, ESMTP and LMTP Transmission Types Registration. Note 238 that it is possible to rephrase RFC 5321bis to avoid this 239 normative reference and the WG will consider doing that. 241 2.7. IESG Feedback 243 The YAM WG requests feedback from the IESG on this decision. In 244 particular: 246 o Does the IESG believe the proposed changes are suitable during a 247 move from Draft to Full Standard? 249 o Excluding the previous proposed changes and expected IESG support 250 for technically substantive IETF last call feedback, does the IESG 251 believe any additional changes are critical to advance this 252 document from draft to full standard? If so, please provide 253 sufficient information so the WG can address these issues prior to 254 IETF last call or determine that the document is inappropriate for 255 the YAM WG to process at this time. 257 o Does the IESG consider the downward references acceptable for a 258 full standard? If not, please cite which specific downward 259 reference or references are problematic and why so the WG can 260 address these issues prior to IETF last call or determine the 261 document is inappropriate for the YAM WG to process at this time. 263 3. IANA Considerations 265 This document contains no IANA actions. 267 4. Security Considerations 269 This document requests IESG feedback and does not raise any security 270 concerns. Security considerations for RFC 5321 have been taken into 271 account during the preliminary evaluation and appear in either 272 Section 2.4 or Section 2.5 of this document. 274 5. Acknowledgments 276 This document was prepared from a template supplied by Subramanian 277 Moonesamy. 279 Some of the information provided in this document, but not provided 280 in the RFC 1652 evaluation (http://www.ietf.org/id/ 281 draft-ietf-yam-rfc1652bis-pre-evaluation-00.txt), was inspired by 282 brief discussions with Pasi Eronen and Subramanian Moonesamy during 283 IETF 76. 285 6. References 287 6.1. Normative References 289 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 290 October 2008. 292 6.2. Informative References 294 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 295 RFC 821, August 1982. 297 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 298 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 299 November 1995. 301 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 302 April 2001. 304 Appendix A. Change Log 306 A.1. Changes from version -01 to -02 308 o Added classes of changes for "errata" and "clarifications". 310 o Included YAM issue tracker numbers in the lists of possible 311 changes. 313 A.2. Changes from version -00 to -01 315 o Added Security Considerations and Examples to the "no change" list 316 in Section 2.5. 318 o Identified RFC 821 as a specific reference to be moved from 319 Normative to Informative. 321 o Add blanket placeholder for changes due to small editorial errors. 323 Authors' Addresses 325 John C Klensin 326 1770 Massachusetts Ave, Ste 322 327 Cambridge, MA 02140 328 USA 330 Phone: +1 617 245 1457 331 Email: john+ietf@jck.com 333 Barry Leiba 334 Huawei Technologies 336 Phone: +1 646 827 0648 337 Email: barryleiba@computer.org 338 URI: http://internetmessagingtechnology.org/