Date: 20 July 2014
RFC 2026 defines a "Historic" status for documents:
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.
However, the only instructions in 2026 for its use are in section 6, and
those are to move full "Internet Standard" status documents to
"Historic" status, thereby "retiring" the technology in the standard.
This differs from the "Obsoletes:" header that is put on documents as
per RFC 2223. The "Obsoletes:" header indicates a replacement version of
the same technology, rather than a retirement of the technology itself.
Using "Obsoletes:" is simply a matter of indicating this in the header
of the RFC. Moving a document to "Historic" status requires a specific
IETF-wide Last Call and a formal action of the IESG.
- A document is obsolete when there is a newer version that replaces
it. RFC 821 is obsoleted by RFC 2821, which is, in turn, obsoleted
by RFC 5321. The technology that RFC 821 describes — SMTP — is still
current technology, but the documentation of it in RFC 821 is
obsolete.
- A document is labelled Historic when what it describes is no longer
considered current: no longer recommended for use.
We have reclassified RFCs as Historic through different mechanisms and
with different documentation over time. All reclassifications have
suffered from a common problem: there is no direct reference from the
RFC that has been made Historic to the explanation of why that action
was taken.
There now exists a new type of document, "status-change" documents, to
fill this gap. These documents are kept in the datatracker, are not
Internet drafts, and are not published as RFCs, but they are archival
documents that are linked to the RFCs whose status is changed. Much as
an Internet draft that requests Historic status might be named "draft-
jones-9191-to-historic", a status-change document requesting that action
might be "status-change-9191-to-historic. Such status change documents
are created by an Area Director, and can be requested by individuals or
working groups.
A major advantage of a status-change document is that it adds
traceability: when the now-Historic RFC is displayed in the datatracker,
there is a pointer directly to the status-change document, making the
explanation more readily accessible. See RFC 5617 for an example:
https://datatracker.ietf.org/doc/rfc5617/
Note the line in the header that says "Status changed by
status-change-adsp-rfc5617-to-historic".
The current process, then, of moving an RFC to Historic status is to
follow one of these, depending upon the level of documentation and
discussion of the documentation required:
1. An AD creates a status-change document containing a relatively
brief explanation of the reason for the status change. A four-week
last call is issued for the status-change document, after which the
IESG evaluates and ballots on the status change. If the change is
approved, the documentation for the change remains in the status-
change document, which is readily available through the datatracker.
This method is best when the explanation is not extensive and does
not need much documentation development. The discussion about
whether the action itself is correct may, of course, still be
extensive.
2. An individual or a working group posts an Internet Draft containing
an explanation of the reason for the status change. The I-D is
discussed and iterated as usual for I-Ds. At some point, it is sent
to an appropriate AD to request publication. The AD creates a
status-change document, with an explanation that points to the I-D.
The I-D and the status-change are then last-called together, after
which the IESG evaluates and ballots on both. If the change is
approved, the content of the I-D is moved into the status-change
document, and the I-D is marked as "dead", having served its
purpose.
This method is best when the explanation is not extensive, but needs
document discussion and development.
3. As #2 above, except that the I-D might also contain other
information. In this case, after IESG approval the I-D is sent to
the RFC Editor. When the RFC is published, the status-change
document is changed to point to the RFC instead of the I-D.
This method is best when the explanation is extensive, the
explanation is part of another piece of work that involves
publication of an RFC, or, in exceptional cases, when the consensus
of the community or of the IESG is that having the information in an
RFC is important.
All cases involve a status-change document, which provides the mechanics
for separately approving the Historic RFC's status change and for tying
the explanation to the Historic RFC. In all cases, the approval of the
status-change document will result in a "Protocol Action" or "Document
Action" announcement.
An RFC may be published directly as Historic, with no earlier status to
change (see, for example, RFC 4870). This is usually done to document
ideas that were considered and discarded, or protocols that were already
historic when it was decided to document them. Those publications are
handled as are any other RFCs. As there is no status change, no status-
change document is used.
Documents having Historic status means that those documents are "not
Internet Standards in any sense," as per RFC 2026.
