I assume we will need to agree to disagree about this, but... --On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker <dhc@xxxxxxxxxxxx> wrote: > If a spec is Historic, it is redundant to say not recommended. > As in, duh... "Duh" notwithstanding, we move documents to Historic for many reasons. RFC 2026 lists "historic" as one of the reasons a document may be "not recommended" (Section 3.3(e)) but says only "superceded... or is for any other reason considered to be obsolete" about Historic (Section 4.2.4). That is entirely consistent with Maturity Levels and Requirement Levels being basically orthogonal to each other, even if "Not Recommended" and "Internet Standard" are presumably mutually exclusive. > Even better is that an applicability statement is merely > another place for the potential implementer to fail to look > and understand. Interesting. If a potential implementer or other potential user of this capability fails to look for the status of the document or protocol, then the reclassification to Historic won't be found and this effort is a waste of the community's time. If, by contrast, that potential user checks far enough to determine that the document has been reclassified to Historic, why is it not desirable to point that user to a superceding document that explains the problem and assigns as requirement status of "not recommended"? The situation would be different if a huge amount of additional work were involved but it seems to me that almost all of the required explanation is already in the write-up and that the amount of effort required to approve an action consisting of a document and a status change is the same as that required to approve the status change only. If creating an I-D from the write-up is considered too burdensome and it would help, I'd be happy to do that rather than continuing to complain. > ADSP is only worthy of a small effort, to correct its status, > to reflect its current role in Internet Mail. Namely, its > universal non-use within email filtering. If the specification had been universally ignored, I'd think that a simple status change without further documentation was completely reasonable. However, the write-up discusses "harm caused by incorrect configuration and by inappropriate use", "real cases", and effects from posts from users. That strongly suggests that this is a [mis]feature that has been sufficiently deployed to cause problems, not someone that is "universally non-used". And that, IMO, calls for a explanation --at least to the extent of the explanation in the write-up-- as to why ADSP was a bad idea, should be retired where it is used, and should not be further deployed. best, john