--On Thursday, October 03, 2013 16:51 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
ADSP was basically an experiment that failed. It has no
significant deployment, and the problem it was supposed to
solve is now being addressed in other ways.
I oppose to the change as proposed, and support the
explanation called for by John Klensin instead. Two arguments:
1) The harm Barry exemplifies in the request
--incompatibility with mailing list posting-- is going to
be a feature of at least one of the other ways addressing
that problem. Indeed, "those who don't know history are
destined to repeat it", and the explanation is needed to
make history known.
2) A possible fix for ADSP is explained by John Levine
himself:
http://www.mail-archive.com/ietf-dkim(_at_)mipassoc(_dot_)org/msg16969.ht
ml I'm not proposing to mention it along with the
explanation, but fixing is not the same as moving to
historic. It seems that it is just a part of RFC 5617,
DNS records, that we want to move.
Ale,
Just to be clear about what I proposed because I'm not sure that
you actually agree: If the situation is as described in the
write-up (and/or as described by John Levine, Murray, and some
other documents), then I'm in favor of deprecating ADSP. The
_only_ issue I'm raising in this case is that I believe that
deprecating a feature or protocol element by moving things to
Historic by IESG action and a note in the tracker is appropriate
only for things that have been completely ignored after an
extended period or that have long ago passed out of public
consciousness. When something has been implemented and
deployed sufficiently that the reason for deprecating it
includes assertions that it has not worked out in practice, I
believe that should be documented in an RFC both to make the
historical record clear and to help persuade anyone who is still
trying to use it to cease doing so.
There may well be arguments for not deprecating the feature, for
improving it in various ways, or for contexts in which its use
would be appropriate, but someone else will have to make them or
propose other remedies. I have not done so nor am I likely to
do so.
best,
john