Re: Question about Obsoleted vs. Historic

On Monday, July 11, 2005 09:54:14 AM +0300 john.loughney@nokia.com 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) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf