I assume we will need to agree to disagree about this, but...
--On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> 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