RFCs and the "Historical" Category

The "Historical" category for RFCs was mentioned in the RFC Series as early as December 1988. The description at that time said "[t]hese are protocols that are unlikely to ever become standards in the Internet either because they have been superseded by later developments or due to lack of interest. These are protocols that are at an evolutionary dead end." The category was most recently specified in Section 4.2.4 of the Internet Standards Process definition . However, the specification there says only "has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level". With one exception, it does not specify what entity makes that assignment, how it is done, and when it is actually appropriate. The exception is the provision for automatic reclassification of standards track documents that have not advanced in Section 6.2 of the Standards Process definition, a provision that was eliminated in 2013 . It is worth noting, for example, the neither the RFC Editor nor the IESG routinely moved earlier documents to Historic when later ones where published that superseded ("obsoleted") except in the case where the replacement documents explicitly specified that action. This memo elaborates on the Historic category (or "level") and defines conditions and mechanisms for placing documents in it. While this is not a protocol specification in the usual sense, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted for the actions and options it specifies as described in RFC 2119.

Part of the long-term difficulty with the Historic category is that, in the past, it was applied to documents for a number of different reasons. This section lists those situations and gives examples of each to provide a proper background.

This is the one category that is explicitly called out by the IETF Standards Process . Documents in this category are associated with a subsequent RFC that contains similar or replacement content and which explicitly identifies the earlier, now obsolete, "Historic" candidate in an "Obsoletes" header and the author wants to make it clear that the older RFC is no longer to be relied upon. RFC 1145 is an example of a document in this category.

Documents fall into this category if they were published but were never implemented or deployed and there is no evidence that anyone expects them to be implemented or deployed in the future. Someone was motivated to reclassify the RFC, most often to minimize the chance that a casual reader would assume that the technology described in the RFC was relevant. RFC 1421 is an example of documents in this category. Documents in this category and the next one have occasionally been classified as Historic and documented as a group. RFC 4450 is an example of that approach.

These are specifications that may have been important at one time but that are believed to no longer be in use and to have no future utility. Protocol specifications that became irrelevant after the transition from the ARPANET to the Internet would fall into this category. The reason to reclassify RFCs in this case is the same as with the last category. RFC 1240 is an example of a document in this category and RFC 2556 is an example of a document reclassifying a RFC to Historic for this reason.

Occasionally a document will be published in the RFC series simply to record something for historical value. These documents may be identified by their authors as Historic at the time of first publication in order to make it clear that the documents are not meant to be implemented. RFC 4156 is an example of documents in this category.

Occasionally, a specification may be published that is later found to be undesirable, less attractive than some alternative, or dangerous or harmful in some way. In this case, the aim of reclassification is to ensure that the technology described in the RFC is not seen as one that should be implemented or used. RFC 1058 is an example of a document in this category and RFC 1923 is an example of a document reclassifying a RFC to Historic for this reason.

There are three main cases for identification of a document as Historic, with applicability based on the categories above.

This group contains documents that were published as Historic ( above), have been explicitly obsoleted by one or more other documents (), or that describe protocols or other topics that are obviously of no further use to, or on, the Internet (). Documents in these categories MAY be classified as Historic by the RFC Editor with the advice and consent of the relevant Stream if one exists. ARPANET-specific documents that, as of the time of this writing, have had a status of "UNKNOWN" for many years MAY be reclassified to Historic by the RFC Editor if a determination is made that they are not referenced by active documents in other categories. The RFC Editor and/or the relevant stream authority are encouraged to consult relevant communities before classifying a document as Historic using this method, but are not required to do so.

Where the conditions above do not apply but a document appears to cover a specification or description that is no longer in use, a stream MAY verify the absence of implementations or deployment by its usual procedures for obtaining consensus from its community to reclassify the document. If there is doubt about that consensus or there appear to be a strong possibility that the specification has been implemented and deployed, the third procedure MUST be used. The stream MUST document the decision in some stable and permanent way according to procedures of its choice. The RFC Editor is responsible for assuring that documentation is readily identified and available to anyone looking for information about the relevant RFC(s).

This procedure applies when neither of the above procedures is applicable and, in particular, when there is reason to believe that the specification or information in the RFC has been implemented, deployed, and that it may still be in use on the Internet or some network that might leak into it. It is also appropriate if the move to Historic is intended to formally deprecate a specification rather than simply record the fact that it is obsolete. For these cases, the stream is expected to prepare a document that describes the reasons for the status change and approve it for RFC publication using the stream's normal procedures. That RFC should explicitly note that it obsoletes the earlier document; the request to move that earlier document to Historic may be part of the RFC or communicated separately. The RFC may be an Applicability Statement (most appropriate if the previous document was Standards Track) or an Informational one that describes the outcome of an earlier experiment or that documents operational experience or a new understanding of the implications of the prior specification or information.

Specifications that the community has concluded are undesirable or dangerous SHOULD normally be formally assigned a status of "Not Recommended" (see Section 3.3(e) of RFC 2026) and MAY be identified as Historic when that is appropriate for other reasons. Because of the existence of other categories and the potential for confusion with them, reclassification to Historic is, by itself, not an appropriate way to deprecate a document or what it specifies.

Any change in the status of a RFC to Historic SHOULD be documented in a way that informs readers as to the reason for the change. The documentation SHOULD be made easily findable and remain accessible for as long as likely that someone might want to refer to the RFC. In the case of the approval and publication of a new RFC that explicitly recategorizes one or more RFCs the new RFC serves as the documentation. In other cases, the existence and location of the documentation should be easy to find from the normal way that people determine the status of RFCs, for example, in the RFC index.

A document may be moved to Historic for multiple reasons, ranging from recognition that it is no longer in use, useful, or applicable to a desire to formally deprecate a specification and warn the community against its use. In general, the former cases should be handled as an administrative procedure: documented as appropriate but not requiring an explanation in the RFC Series. By contrast, when a protocol that is in active use (even if only a few places) is to be deprecated, that action and the reasons for it should be documented in the RFC Series and should receive the same levels of review and consensus as the document it proposes to deprecate and make Historic. The principle is that, unless something was never implemented or taken seriously or has become completely unused over time, undoing its approval and any implicit recommendation (even a recommendation for experimentation) should require the same process of approval and publication as was needed to approve it initially. Anything else risks both confusing readers of the RFC Series and questions about the fairness of the actions taken.

This document was developed as an alternative to an appeal of an IESG action that classified a specification that had been implemented and deployed as Historic without documentation in the RFC series of the reasons for that action. The issues are discussed in more detail in .

This memo includes no requests to or actions for IANA. It is, however, important to check that any document being proposed for Historic status neither contains the definitions of, nor is referenced from, any IANA registry without clarification of the status of the registry or registry entry. That clarification might require publication of an RFC even if the category of the document itself does not.

While this specification should have no direct effect on Internet Security, some of its provisions will have the effect of getting specifications that are found to pose security risks appropriate documented so as to warn the community, rather than creating doubt about why the specification was made Historic.