IETF J.C. Klensin Internet-Draft S. Bradner Updates: 2026 (if approved) Harvard University Intended status: Best Current Practice February 10, 2014 Expires: August 12, 2014 RFCs and the "Historical" Category draft-klensin-historical-definition-00.txt Abstract The "Historical" category has been used to identify some documents in the RFC Series for many years, but has never been precisely defined except in various oral traditions. More important, with one exception that is now obsolete, the conditions under which documents should be reclassified as Historic and the procedures for doing so have never been defined, leading to a number of ad hoc and inconsistent actions. This document clarifies both the category and procedures for putting documents into it. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 12, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text Klensin & Bradner Expires August 12, 2014 [Page 1]
Internet-Draft Historical RFCs February 2014 as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and History . . . . . . . . . . . . . . . . . . . 2 2. A Typology of Documents that Have Been Placed in the Historic Category . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Obsoleted by another document . . . . . . . . . . . . . . 3 2.2. Published but ignored . . . . . . . . . . . . . . . . . . 3 2.3. Documents that are no longer relevant to the Internet . . 4 2.4. Specifications published purely for historical value . . . 4 2.5. Specifications that are believed to be undesirable or dangerous in some way . . . . . . . . . . . . . . . . . . 4 3. Procedures for Classification as Historic . . . . . . . . . . 5 3.1. Case 1: Clearly Obsolete and Irrelevant for Future Development . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Case 2: Obsolescent documents requiring formal action . . 5 3.3. Case 3: Deprecation and other situations requiring consensus decisions . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Interaction with Applicability Statements . . . . . . . . . . 6 5. Documenting Status Changes . . . . . . . . . . . . . . . . . . 6 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction and History 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." [RFC1083] The category was most recently specified in Section 4.2.4 of the Internet Standards Process definition [RFC2026]. 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 [RFC6410]. 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 Klensin & Bradner Expires August 12, 2014 [Page 2]
Internet-Draft Historical RFCs February 2014 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 [RFC2119]. 2. A Typology of Documents that Have Been Placed in the Historic Category 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. 2.1. Obsoleted by another document This is the one category that is explicitly called out by the IETF Standards Process [RFC2026]. 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 [RFC1145] is an example of a document in this category. 2.2. Published but ignored 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 [RFC1421] is an example of documents in this category. Klensin & Bradner Expires August 12, 2014 [Page 3]
Internet-Draft Historical RFCs February 2014 Documents in this category and the next one have occasionally been classified as Historic and documented as a group. RFC 4450 [RFC4450] is an example of that approach. 2.3. Documents that are no longer relevant to the Internet 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 [RFC1240] is an example of a document in this category and RFC 2556 [RFC2556] is an example of a document reclassifying a RFC to Historic for this reason. 2.4. Specifications published purely for historical value 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 [RFC4156] is an example of documents in this category. 2.5. Specifications that are believed to be undesirable or dangerous in some way 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 [RFC1058] is an example of a document in this category and RFC 1923 [RFC1923] is an example of a document reclassifying a RFC to Klensin & Bradner Expires August 12, 2014 [Page 4]
Internet-Draft Historical RFCs February 2014 Historic for this reason. 3. Procedures for Classification as Historic There are three main cases for identification of a document as Historic, with applicability based on the categories above. 3.1. Case 1: Clearly Obsolete and Irrelevant for Future Development This group contains documents that were published as Historic (Section 2.4 above), have been explicitly obsoleted by one or more other documents (Section 2.1), or that describe protocols or other topics that are obviously of no further use to, or on, the Internet (Section 2.2). 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. 3.2. Case 2: Obsolescent documents requiring formal action 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). 3.3. Case 3: Deprecation and other situations requiring consensus decisions Klensin & Bradner Expires August 12, 2014 [Page 5]
Internet-Draft Historical RFCs February 2014 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. 4. Interaction with Applicability Statements 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. 5. Documenting Status Changes 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. 6. Summary Klensin & Bradner Expires August 12, 2014 [Page 6]
Internet-Draft Historical RFCs February 2014 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. 7. Acknowledgements 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 Section 6. 8. IANA Considerations 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. 9. Security Considerations 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. 10. References 10.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Klensin & Bradner Expires August 12, 2014 [Page 7]
Internet-Draft Historical RFCs February 2014 10.2. Informative References [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988. [RFC1083] Postel, J., "IAB official protocol standards", RFC 1083, December 1988. [RFC1145] Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1145, February 1990. [RFC1240] Shue, C., Haggerty, W. and K. Dobbins, "OSI connectionless transport services on top of UDP: Version 1", RFC 1240, June 1991. [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996. [RFC2556] Bradner, S., "OSI connectionless transport services on top of UDP Applicability Statement for Historic Status", RFC 2556, March 1999. [RFC4156] Hoffman, P., "The wais URI Scheme", RFC 4156, August 2005. [RFC4450] Lear, E. and H. Alvestrand, "Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents", RFC 4450, March 2006. [RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011. Authors' Addresses John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Scott Bradner Harvard University Email: sob@harvard.edu Klensin & Bradner Expires August 12, 2014 [Page 8]