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.