--On Saturday, November 2, 2024 17:05 +0000 Pete Resnick <resnick=40episteme.net@xxxxxxxxxxxxxx> wrote: > On 2 Nov 2024, at 14:34, Eric Rescorla wrote: > >> I see this document as something of an intermediate case: while >> SMTP is of course part of a broader suite of mail protocols, this >> is the document that is concerned with transport and so it would >> probably be better to have the material that is also related to >> transport such as STARTTLS in this document specifically. OTOH, >> given the long history of this document and the existence of the >> A/S, I also think it would be OK to have a more consolidated >> security discussion there, provided that it's actually normatively >> referneced by this document. >> >> What I don't think is reasonable is to have that material appear >> nowhere or outside of the normative references, because that >> doesn't fulfill the overall objective of having them as part of >> the protocol description. Note that I'm *not* asking here for any >> new normative text--although I know others have suggested it--but >> merely for a clear description of the situation, as described in >> RFC 3552. > > Would it be sufficient to have the A/S marked as "Updates: 5321bis"? Pete, Two small problems there. One is that the A/S contains discussions that reflect on (I'm reluctant to say "updates" for the reasons below) 5322bis as well and I don't think we know how to give one document two STD numbers. The other is that, at the moment (and going back to RFC 1425 in 1993), while the extension mechanism itself is "part of" SMTP (and hence 5321bis), individual extensions are not. We've done a fairly good job holding that line; if we breach it and say, e.g., STARTTS is really part of SMTP, then where do we draw the line? In particular, at a time when the IETF is concerned about outreach and a global Internet, can we justify saying that SMTPUTF8 (i.e., RFC 6351) is not part of SMTP if other extensions are? > The concern I have is that we can't have a document at Internet > Standard normatively referencing a Proposed Standard. I'm pretty > sure that the A/S can be pretty quickly moved to IS and added to > STD 10, but holding up the publication of 5321bis (and not finally > getting 821 out as the IS reference for SMTP) would be less than > ideal. Agreed. And, speaking personally (and consistent with what I've said to the WG for a few years now), I don't think I can devote full attention to the A/S until 5321bis is clearly under control and that might have an impact on its schedule. Possible compromise suggestion if it would get things moving forward: At least parts of the discussion have been about a normative reference from the Security Considerations section of 5321bis to the discussion of STARTTLS and associated Security Consideration in the A/S. I've discussed possible text with a few people and there is a pointer and some suggestions in the current version of the working draft. For reasons that are probably clear and definitely include that normative reference issue, I'm not happen about it. But it has occurred to me in this discussion, while I proofread a further response to Paul's comments, and as I try to finish up my response to Donald's review (all prerequisite to my getting that highly annotated working draft posted) that maybe we could do something else. Section 1 of 5321bis contains a discussion of the document, what it covers and what it does not, how it got to be the way it is, and so on. It would not be hard to add a few sentences (or a new subsection there) that said, very much Informationally, that there are three documents that make up the core of the IETF email specs -- 5321bis, 5322bis, and the forthcoming A/S -- that provides additional information about operational considerations, relationships to other specifications including selected SMTP extensions, and related issues including security conditions associated with those relationships. If desired, I could include a pointer to that explanation in the Security Considerations section. A clear pointer without getting up hung up in normative references, breaching the boundary between SMTP and its extensions, and not limited to security (because there are other issues affected). If it works for people and you / the WG wanted, we could stuff similar text into 5322bis but I don't think it is necessary. Does that help? john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
