idnits 2.17.1 draft-ietf-emailcore-as-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 6, 2020) is 1298 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) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1341 (Obsoleted by RFC 1521) -- Obsolete informational reference (is this intentional?): RFC 1425 (Obsoleted by RFC 1651) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Duplicate reference: RFC5321, mentioned in 'RFC5321', was also mentioned in 'ID.RFC5321bis'. -- Duplicate reference: RFC5322, mentioned in 'RFC5322', was also mentioned in 'ID.RFC5322bis'. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMAILCORE J. Klensin, Ed. 3 Internet-Draft October 6, 2020 4 Intended status: Standards Track 5 Expires: April 9, 2021 7 Applicability Statement for IETF Core Email Protocols 8 draft-ietf-emailcore-as-00 10 Abstract 12 Electronic mail is one of the oldest Internet applications that is 13 still in very active use. While the basic protocols and formats for 14 mail transport and message formats have evolved slowly over the 15 years, events and thinking in more recent years have supplemented 16 those core protocols with additional features and suggestions for 17 their use. This Applicability Statement describes the relationship 18 among many of those protocols and provides guidance and makes 19 recommendations for the use of features of the core protocols. 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 https://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 April 9, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 (https://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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3 57 3. Applicability of Message Format Provisions . . . . . . . . . 3 58 4. MIME and Its Implications . . . . . . . . . . . . . . . . . . 3 59 5. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 9.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 67 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) 68 to draft-ietf-emailcore-as-00 . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 In its current form, this draft is a placeholder and beginning of an 74 outline for the Applicability Statement that has been discussed as a 75 complement for proposed revisions of the base protocol specifications 76 for SMTP [RFC5321] (being revised as ID.RFC5321bis [ID.RFC5321bis]) 77 and Internet Message Format [RFC5322] (being revised as ID.RFC5322bis 78 [ID.RFC5322bis]). Among other things, it is expected to capture 79 topics that a potential WG concludes are important but that should 80 not become part of those core documents. 82 As discussed in RFC 2026 [RFC2026], 84 "An Applicability Statement specifies how, and under what 85 circumstances, one or more TSs may be applied to support a 86 particular Internet capability." 88 That form of a standards track document is appropriate because one of 89 the roles of such a document is to explain the relationship among 90 technical specification, describe how they are used together, and 91 make statements about what is "required, recommended, or elective". 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119] and 96 RFC 8174 [RFC8174]. 98 2. Applicability of Some SMTP Provisions 100 Over the years since RFC 5321 was published in October 2008, usage of 101 SMTP has evolved, machines and network speeds have increased, and the 102 frequency with which SMTP senders and receivers have to be prepared 103 to deal with systems that are disconnected from the Internet for long 104 periods or that require many hops to reach has decreased. During the 105 same period, the IETF has become much more sensitive to privacy and 106 security issues and the need to be more resistant or robust against 107 spam and other attacks. In addition SMTP (and Message Format) 108 extensions have been introduced that are expected to evolve the 109 Internet's mail system to better accommodate environments in which 110 Basic Latin Script is not the norm. 112 This section describes adjustments that may be appropriate for SMTP 113 under various circumstances and discusses the applicability of other 114 protocols that represent newer work or that are intended to deal with 115 relatively newer issues. 117 [[CREF1: ... Actual content to be supplied after WG consideration. 118 ]] 120 3. Applicability of Message Format Provisions 122 Placeholder: 123 I am not sure what, if anything, goes here. If nothing does, we drop 124 the section. 126 [[CREF2: ... Actual content to be supplied after WG consideration.]] 128 4. MIME and Its Implications 130 When the work leading to the original version of the MIME 131 specification was completed in 1992 [RFC1341], the intention was that 132 it be kept separate from the specification for basic mail headers in 133 RFC 822 [RFC0822]. That plan was carried forward into RFC 822's 134 successors, RFC 2822 [RFC2822] and RFC 5322 [RFC5322] and the 135 successors of that original MIME specification including RFC 2045 136 [RFC2045]. The decision to do so was different from the one made for 137 SMTP, for which the core specification was changed to allow for the 138 extension mechanism [RFC1425] which was then incorporated into RFC 139 5321 and its predecessor [RFC2821]. 141 Various uses of MIME have become nearly ubiquitous in contemporary 142 email while others may have fallen into disuse or been repurposed 143 from the intent of their original design. 145 It may be appropriate to make some clear statements about the 146 applicability of MIME and its features. 148 5. Other Stuff 150 It is fairly clear that there will be things that do not fit into the 151 sections outlined above. As one example, if the IETF wants to say 152 something specific about signatures over headers or what (non-trace) 153 headers may reasonably be altered in transit, that may be more 154 appropriate to other sections than to any of the three suggested 155 above. 157 6. Acknowledgments 159 ... To be supplied... 160 [[CREF3: But don't forget to mention the discussions on the SMTP list 161 of the reasons for this document in the last half of 2019. ]] 163 7. IANA Considerations 165 This memo includes no requests to or actions for IANA. The IANA 166 registries associated with the protocol specifications it references 167 are specified in their respective documents. 169 8. Security Considerations 171 All drafts are required to have a security considerations section and 172 this one eventually will. 174 ... To be supplied ... 176 9. References 178 9.1. Normative References 180 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 181 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 182 . 184 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 185 Extensions (MIME) Part One: Format of Internet Message 186 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 187 . 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, 191 DOI 10.17487/RFC2119, March 1997, 192 . 194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 196 May 2017, . 198 9.2. Informative References 200 [ID.RFC5321bis] 201 Klensin, J., "Simple Mail Transfer Protocol", December 202 2019, . 205 [ID.RFC5322bis] 206 Resnick, P., "Internet Message Format", December 2019, 207 . 210 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 211 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 212 August 1982, . 214 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 215 Mail Extensions): Mechanisms for Specifying and Describing 216 the Format of Internet Message Bodies", RFC 1341, 217 DOI 10.17487/RFC1341, June 1992, 218 . 220 [RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 221 D. Crocker, "SMTP Service Extensions", February 1993, 222 . 224 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 225 RFC 2821, DOI 10.17487/RFC2821, April 2001, 226 . 228 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 229 DOI 10.17487/RFC2822, April 2001, 230 . 232 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 233 DOI 10.17487/RFC5321, October 2008, 234 . 236 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 237 DOI 10.17487/RFC5322, October 2008, 238 . 240 Appendix A. Change Log 242 RFC Editor: Please remove this appendix before publication. 244 A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft- 245 ietf-emailcore-as-00 247 o Change of filename, metadata, and date to reflect transition to WG 248 document for new emailcore WG. No other substantive changes 250 Author's Address 252 John C Klensin (editor) 253 1770 Massachusetts Ave, Ste 322 254 Cambridge, MA 02140 255 USA 257 Phone: +1 617 245 1457 258 Email: john-ietf@jck.com