idnits 2.17.1 draft-klensin-email-core-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 (March 30, 2020) is 1485 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) == Unused Reference: 'RFC2045' is defined on line 180, but no explicit reference was found in the text -- 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 (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin, Ed. 3 Internet-Draft March 30, 2020 4 Intended status: Standards Track 5 Expires: October 1, 2020 7 Applicability Statement for IETF Core Email Protocols 8 draft-klensin-email-core-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 October 1, 2020. 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 In its current form, this draft is a placeholder and beginning of an 71 outline for the Applicability Statement that has been discussed as a 72 complement for proposed revisions of the base protocol specifications 73 for SMTP [RFC5321] (being revised as ID.RFC5321bis [ID.RFC5321bis]) 74 and Internet Message Format [RFC5322] (being revised as ID.RFC5322bis 75 [ID.RFC5322bis]). Among other things, it is expected to capture 76 topics that a potential WG concludes are important but that should 77 not become part of those core documents. 79 As discussed in RFC 2026 [RFC2026], 81 "An Applicability Statement specifies how, and under what 82 circumstances, one or more TSs may be applied to support a 83 particular Internet capability." 85 That form of a standards track document is appropriate because one of 86 the roles of such a document is to explain the relationship among 87 technical specification, describe how they are used together, and 88 make statements about what is "required, recommended, or elective". 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119] and 93 RFC 8174 [RFC8174]. 95 2. Applicability of Some SMTP Provisions 97 Over the years since RFC 5321 was published in October 2008, usage of 98 SMTP has evolved, machines and network speeds have increased, and the 99 frequency with which SMTP senders and receivers have to be prepared 100 to deal with systems that are disconnected from the Internet for long 101 periods or that require many hops to reach has decreased. During the 102 same period, the IETF has become much more sensitive to privacy and 103 security issues and the need to be more resistant or robust against 104 spam and other attacks. In addition SMTP (and Message Format) 105 extensions have been introduced that are expected to evolve the 106 Internet's mail system to better accommodate environments in which 107 Basic Latin Script is not the norm. 109 This section describes adjustments that may be appropriate for SMTP 110 under various circumstances and discusses the applicability of other 111 protocols that represent newer work or that are intended to deal with 112 relatively newer issues. 114 [[CREF1: ... Actual content to be supplied after WG consideration. 115 ]] 117 3. Applicability of Message Format Provisions 119 Placeholder: 120 I am not sure what, if anything, goes here. If nothing does, we drop 121 the section. 123 [[CREF2: ... Actual content to be supplied after WG consideration.]] 125 4. MIME and Its Implications 127 When the work leading to the original version of the MIME 128 specification was completed in 1992 [RFC1341], the intention was that 129 it be kept separate from the specification for basic mail headers in 130 RFC 822 [RFC0822]. That plan was carried forward into RFC 822's 131 successors, RFC 2822 [RFC2822] and RFC 5322 [RFC5322]. The decision 132 to do so was different from the one made for SMTP, for which the core 133 specification was changed to allow for the extension mechanism 134 [RFC1425] which was then incorporated into RFC 5321 and its 135 predecessor [RFC2821]. 137 Various uses of MIME have become nearly ubiquitous in contemporary 138 email while others may have fallen into disuse or been repurposed 139 from the intent of their original design. 141 It may be appropriate to make some clear statements about the 142 applicability of MIME and its features. 144 5. Other Stuff 146 It is fairly clear that there will be things that do not fit into the 147 sections outlined above. As one example, if the IETF wants to say 148 something specific about signatures over headers or what (non-trace) 149 headers may reasonably be altered in transit, that may be more 150 appropriate to other sections than to any of the three suggested 151 above. 153 6. Acknowledgments 155 ... To be supplied... 156 [[CREF3: But don't forget to mention the discussions on the SMTP list 157 of the reasons for this document in the last half of 2019. ]] 159 7. IANA Considerations 161 This memo includes no requests to or actions for IANA. The IANA 162 registries associated with the protocol specifications it references 163 are specified in their respective documents. 165 8. Security Considerations 167 All drafts are required to have a security considerations section and 168 this one eventually will. 170 ... To be supplied ... 172 9. References 174 9.1. Normative References 176 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 177 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 178 . 180 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 181 Extensions (MIME) Part One: Format of Internet Message 182 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 183 . 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 191 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 192 May 2017, . 194 9.2. Informative References 196 [ID.RFC5321bis] 197 Klensin, J., "Simple Mail Transfer Protocol", December 198 2019, . 201 [ID.RFC5322bis] 202 Resnick, P., "Internet Message Format", December 2019, 203 . 206 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 207 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 208 August 1982, . 210 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 211 Mail Extensions): Mechanisms for Specifying and Describing 212 the Format of Internet Message Bodies", RFC 1341, 213 DOI 10.17487/RFC1341, June 1992, 214 . 216 [RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and 217 D. Crocker, "SMTP Service Extensions", February 1993, 218 . 220 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 221 RFC 2821, DOI 10.17487/RFC2821, April 2001, 222 . 224 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 225 DOI 10.17487/RFC2822, April 2001, 226 . 228 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 229 DOI 10.17487/RFC5321, October 2008, 230 . 232 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 233 DOI 10.17487/RFC5322, October 2008, 234 . 236 Author's Address 238 John C Klensin (editor) 239 1770 Massachusetts Ave, Ste 322 240 Cambridge, MA 02140 241 USA 243 Phone: +1 617 245 1457 244 Email: john-ietf@jck.com