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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf