>> Steve and I went through and took out stuff that looks too much like >> an implementor's guide rather than an applicability statement. In >> particular, we tried to stick to what to accomplish, not how to do it. >> >> There's nothing wrong with writing a DKIM or SPF reporting cookbook, >> but this isn't it. > > OK. Now that I've read the relevant standard, I'm more convinced than ever > this proposed change is a step in the wrong direction. The first section of > RFC 2026, paragraph 3.2 says:
I can give the WG my opinion, as a contributor, a chair, and now an AD, on what an Applicability Statement should be. We have little recent experience with the AS idea -- its function has mostly been either included in Technical Specifications (TS), pushed into a non-standards-track Informational document (as in the DKIM operational guide), or published as a BCP. A TS, such as RFC 5965 (MARF base), is meant to describe the details of the protocol, while an AS is for explaining how to use the protocol in practice. It's often difficult to decide where to draw the line between what should go in the TS and what qualifies as AS material. But I think there's a lot of flexibility in deciding what qualifies for an AS. As chair (and, soon, as AD), my opinion goes toward inclusion. The working group has to decide what it has rough consensus to include, of course. That said, I recommend that it include what advice would be useful to use these protocols to best effect and greatest level of interoperability in the real world... considering that this advice can advance along the standards track along with the protocol documents themselves, getting revisions as appropriate along the way (which is one thing that distinguishes an AS from a BCP). Because the AS is a Standards Track document, it theoretically carries more weight than an Informational document, and the WG should consider what should be specified as advice on the Standards Track, and what really *is* just information. That said, purely informational content can be included in the AS and be so labelled. But stuff that's important to getting your abuse reports done right and accepted by report consumers should be in here. Stuff that's important to report consumers for correctly handling abuse reports should be in here. I'm not sure why there's such a strong desire among some to eliminate text, so perhaps you can explain that. My preference (as a participant), and my advice (as a chair) is to include more information, as long, of course, as we think that information is correct. If we're cutting content because we don't agree with it, we should do that. If we're cutting content just to make the document shorter, I question the need for that. If we're cutting content because we think an "AS" shouldn't have that sort of stuff in it, let's think about that carefully, and explain why. If it helps implementors get things right and interoperate better, or helps implementors better understand how multiple standards work together, I think it's exactly what belongs in an AS. Barry _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
