RFCs and the "Historical" Category
draft-klensin-historical-definition-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors John Klensin  , Scott Bradner 
Last updated 2014-02-10
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text