On 20 Jul 2011, at 01:41, Joel Jaeggli wrote:
On Jul 19, 2011, at 2:34 PM, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive. No standards body could seek to stand behind their
specifications, or to give the impression of doing so, with such a position.
That's a fairly odd position to take, if we do something which turns out to
be a bad idea, should we stand behind it regardless of the validity of the
No. But if it's in active use, we have something of an obligation to the
users. The fact that it's in use is a fairly clear indication, regardless of
technical quality (the review process being meant as an aid to identifying the
more obvious problems before publication) that it is or can be made to be
useful. That's an argument in favour. I don't dispute that protocols can turn
out to be harmful, and there's a good vs bad benefit analysis to be made for
lots of different reasons, but as has already been said before, the historic
label is an *extremely* blunt instrument that is almost always reserved for
specifications that have actually come to rest, following the logical English
definition of "Historic" or "Historical". Better for the community to be
informed about the good and bad of protocols with troublesome aspects.
The number of drafts, I've seen over the course of the last decade and a half
with the title "foo considered harmful" woulkd tend to indicate otherwise.
Define "active use."
If in fact no-one were using it there would be little point in engaging in
Right, precisely. If the call weren't made, or it were made but happily
ignored by everyone, I think we can take it as red that nobody minds too much.
rfc 5095 and 4966 were not created to address issues that were due to
protocols being dead to the world...
Well, FWIW, NAT-PT is still implemented and in use, most recently for evil
purposes. But once again, the designation means that the protocol has reached
the end of its useful service life; there is no further use that can't be
better served with our newer, shinier standards. That is something we
explicitly indicate, so implementers can get on and implement the better
solution. And in every case, we have "Applicability statements" or "Reasons to
move" documents, so the community understands.
Ietf mailing list