Bob,
A question for you:
What is the reason for continuing to list something obsolete as a Draft
Standard?
Because Jon Postel always did it that way? Seriously, the idea is that the
document was a Draft Standard when it was published. You can obsolete
it, but you cannot change its publication status. Should its status change
to
Historic when it is obsoleted? Maybe, although we have never done it that way
(and we do have 20+ years of history).
First off, 2026 says:
4.2.4 Historic
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level.
So, it would appear, to me, that anything that has been obsoleted is, in fact,
Historic. But perhaps I am nit-picking.
My question is - what do we mean by an Obsoleted Proposed Standard? Does this
have any relevance? What I am still confused about is that, for a particular
technology, what does the IETF 'recommend' or would want to see implemented
for a particular standard? Obviously, Historic carries the connotation that
the IETF doesn't suggest to be implemented. Does the IETF think that Standards
that have been Obsoleted SHOULD be implemented or SHOULD NOT be implemented?
If I wanted to do something and had 2 protocols to choose from, one that was
Proposed Standard and one that was Obsolete but Full Standard, which one
would the IETF like that I implement?
Perhaps I am asking to much from the RFC Index
(http://www.ietf.org/iesg/1rfc_index.txt)
but one would think that we could provide a meaningful way to convey what
we think of our own technology?
(Note that in fact the RFC Editor added "publication status" to its
index
database last year; the new field is included in rfc-index.xml. This
shows the status upon publication, in cases where the status is
changed later.)
There are quite a few twisty little passages lurking here, and they mostly
stem from
a basic semantic confusion between a document (RFC) number and the protocol
that is specified in that document (or maybe not). The RFC number is in fact
a
document number, but we have chosen to overload it as a protocol designator.
We say "RFC 793" or "TCP" more or less interchangeably, but 793 is really
only a document.
In my view, a result of the ISD proposal in newtrk should be to cleanly
remove this
semantic overloading of RFC numbers. An ISD would define a protocol
independent of
a document identifier (RFC number). I believe that we should move with all
deliberate speed to engineer an ISD-based system for IETF standards, rather
than
to make small patches to RFC designations.
Well, you can guess my position on this as well.
thanks,
John
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf