[newtrk] Re: Question about Obsoleted vs. Historic

[Jeffrey Hutzelman <[e-mail]>]

On Monday, July 11, 2005 09:54:14 AM +0300 [e-mail] wrote:

> Hi,
>
> I was wondering if someone could help me out on this one.  I was doing a
> bit of analysis on the current RFC list, and noticed that some Draft
> Standard documents are obsoleted.  For example:
>
>  954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler.
>       Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted
>       by RFC3912) (Status: DRAFT STANDARD)
>
> This really made me scratch my head. One would imagine if a protocol is
> obsoleted by another, it would not be listed as a Draft Standard any
> longer.
>
> What is the reason for continuing to list something obsolete as a Draft
> Standard?

I think there is a bit of confusion here.

"Obsoleted by RFCxxxx" does _not_ mean that the technology or protocol
described in the present document is obsolete.  It does not even mean that
the specification contained in the document is obsolete.  What it means is
that RFCxxxx contains a newer version of the same specification, which
stands on its own.  By contrast, "Updated by RFCxxxx" means that RFCxxxx
extends or updates the specificiation, possibly even resulting in a new
version, but also requires reading the present document -- it does not
stand on its own.

Described another way, if one document "updates" another, it is the moral
equivalent of a patch.  If a document "obsoletes" another, then it is like
a complete copy of the new file (and often is exactly that).


These notations are intended to help find older and newer versions of a
specification, extensions, base documents, etc.  They are entirely about
document history, and are orthogonal to the progression of a specification
through the standards process.  For example, it is entirely reasonable and
even common to have "RFCxxxx obsoletes RFCyyyy", where RFCxxxx is at
Proposed and RFCyyyy is at Draft or is even a full standard.



Now in the particular case at hand, it is entirely possible and even likely
that the intent is for RFC3912 (also at Draft) to eventually progress to
full standard in the place of RFC954.  It can be reasonably argued that in
such a case, the publication status of RFC954 should be changed, and even
that it should have been changed by RFC3912.  It's just (apparently) not
what has always been done.


-- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html