ietf
[Top] [All Lists]

Re: Question about Obsoleted vs. Historic

2005-07-11 18:09:42


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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf