rfc1602.txt

RFC 的详细文档！

      a standards track or Experimental protocol, the corresponding
      technical specifications provide the required documentation for
      IANA.  For a proprietary protocol, the IANA will keep confidential
      any writeup that is supplied, but at least a short (2 page)
      writeup is still required for an assignment.

2.  NOMENCLATURE

   2.1  The Internet Standards Track

      Specifications that are destined to become Internet Standards
      evolve through a set of maturity levels known as the "standards
      track".  These maturity levels -- "Proposed Standard", "Draft
      Standard", and "Standard" -- are defined and discussed below in
      Section 3.2.

      Even after a specification has been adopted as an Internet
      Standard, further evolution often occurs based on experience and
      the recognition of new requirements.  The nomenclature and
      procedures of Internet standardization provide for the replacement
      of old Internet Standards with new ones, and the assignment of
      descriptive labels to indicate the status of "retired" Internet
      Standards.  A set of maturity levels is defined in Section 3.3 to
      cover these and other "off-track" specifications.



IAB - IESG                                                     [Page 11]

RFC 1602               Internet Standards Process             March 1994


   2.2  Types of Specifications

      Specifications subject to the Internet standardization process
      fall into two categories:  Technical Specifications (TS) and
      Applicability Statements (AS).

      2.2.1  Technical Specification (TS)

         A Technical Specification is any description of a protocol,
         service, procedure, convention, or format.  It may completely
         describe all of the relevant aspects of its subject, or it may
         leave one or more parameters or options unspecified.  A TS may
         be completely self-contained, or it may incorporate material
         from other specifications by reference to other documents
         (which may or may not be Internet Standards).

         A TS shall include a statement of its scope and the general
         intent for its use (domain of applicability).  Thus, a TS that
         is inherently specific to a particular context shall contain a
         statement to that effect.  However, a TS does not specify
         requirements for its use within the Internet; these
         requirements, which depend on the particular context in which
         the TS is incorporated by different system configurations, is
         defined by an Applicability Statement.

      2.2.2  Applicability Statement (AS)

         An Applicability Statement specifies how, and under what
         circumstances, one or more TSs are to be applied to support a
         particular Internet capability.  An AS may specify uses for TSs
         that are not Internet Standards, as discussed in Section 4.

         An AS identifies the relevant TSs and the specific way in which
         they are to be combined, and may also specify particular values
         or ranges of TS parameters or subfunctions of a TS protocol
         that must be implemented.  An AS also specifies the
         circumstances in which the use of a particular TS is required,
         recommended, or elective.

         An AS may describe particular methods of using a TS in a
         restricted "domain of applicability", such as Internet routers,
         terminal servers, Internet systems that interface to Ethernets,
         or datagram-based database servers.

         The broadest type of AS is a comprehensive conformance
         specification, commonly called a "requirements document", for a



IAB - IESG                                                     [Page 12]

RFC 1602               Internet Standards Process             March 1994


         particular class of Internet systems, such as Internet routers
         or Internet hosts.

         An AS may not have a higher maturity level in the standards
         track than any standards-track TS to which the AS applies.  For
         example, a TS at Draft Standard level may be referenced by an
         AS at the Proposed Standard or Draft Standard level, but not by
         an AS at the Standard level.

         An AS may refer to a TS that is either a standards-track speci-
         fication or is "Informational", but not to a TS with a maturity
         level of "Prototype", "Experimental", or "Historic" (see
         section 2.4).

      Although TSs and ASs are conceptually separate, in practice a
      standards-track document may combine an AS and one or more related
      TSs.  For example, Technical Specifications that are developed
      specifically and exclusively for some particular domain of
      applicability, e.g., for mail server hosts, often contain within a
      single specification all of the relevant AS and TS information.
      In such cases, no useful purpose would be served by deliberately
      distributing the information among several documents just to
      preserve the formal AS/TS distinction.  However, a TS that is
      likely to apply to more than one domain of applicability should be
      developed in a modular fashion, to facilitate its incorporation by
      multiple ASs.

   2.3  Standards Track Maturity Levels

      ASs and TSs go through stages of development, testing, and
      acceptance.  Within the Internet standards process, these stages
      are formally labeled "maturity levels".

      This section describes the maturity levels and the expected
      characteristics of specifications at each level.

      2.3.1  Proposed Standard

         The entry-level maturity for the standards track is "Proposed
         Standard".  A Proposed Standard specification is generally
         stable, has resolved known design choices, is believed to be
         well-understood, has received significant community review, and
         appears to enjoy enough community interest to be considered
         valuable.  However, further experience might result in a change
         or even retraction of the specification before it advances.




IAB - IESG                                                     [Page 13]

RFC 1602               Internet Standards Process             March 1994


         Usually, neither implementation nor operational experience is
         required for the designation of a specification as a Proposed
         Standard.  However, such experience is highly desirable, and
         will usually represent a strong argument in favor of a Proposed
         Standard designation.

         The IESG may require implementation and/or operational
         experience prior to granting Proposed Standard status to a
         specification that materially affects the core Internet
         protocols or that specifies behavior that may have significant
         operational impact on the Internet.  Typically, such a
         specification will be published initially with Experimental or
         Prototype status (see below), and moved to the standards track
         only after sufficient implementation or operational experience
         has been obtained.

         A Proposed Standard should have no known technical omissions
         with respect to the requirements placed upon it.  However, the
         IESG may recommend that this requirement be explicitly reduced
         in order to allow a protocol to advance into the Proposed
         Standard state, when a specification is considered to be useful
         and necessary (and timely), even absent the missing features.

         Implementors should treat Proposed Standards as immature
         specifications.  It is desirable to implement them in order to
         gain experience and to validate, test, and clarify the
         specification.  However, since the content of Proposed
         Standards may be changed if problems are found or better
         solutions are identified, deploying implementations of such
         standards into a disruption-sensitive customer base is not
         normally advisable.

      2.3.2  Draft Standard

         A specification from which at least two independent and
         interoperable implementations have been developed, and for
         which sufficient successful operational experience has been
         obtained, may be elevated to the "Draft Standard" level.  This
         is a major advance in status, indicating a strong belief that
         the specification is mature and will be useful.

         A Draft Standard must be well-understood and known to be quite
         stable, both in its semantics and as a basis for developing an
         implementation.  A Draft Standard may still require additional
         or more widespread field experience, since it is possible for
         implementations based on Draft Standard specifications to



IAB - IESG                                                     [Page 14]

RFC 1602               Internet Standards Process             March 1994


         demonstrate unforeseen behavior when subjected to large-scale
         use in production environments.

      2.3.3  Internet Standard

         A specification for which significant implementation and
         successful operational experience has been obtained may be
         elevated to the Internet Standard level.  An Internet Standard
         (which may simply be referred to as a Standard) is
         characterized by a high degree of technical maturity and by a
         generally held belief that the specified protocol or service
         provides significant benefit to the Internet community.

         A Draft Standard is normally considered to be a final
         specification, and changes are likely to be made only to solve
         specific problems encountered.  In most circumstances, it is
         reasonable for vendors to deploy implementations of draft
         standards into the customer base.

   2.4  Non-Standards Track Maturity Levels

      Not every TS or AS is on the standards track.  A TS may not be
      intended to be an Internet Standard, or it may be intended for
      eventual standardization but not yet ready to enter the standards
      track.  A TS or AS may have been superseded by more recent
      Internet Standards, or have otherwise fallen into disuse or
      disfavor.

      Specifications not on the standards track are labeled with one of
      four off-track maturity levels: "Prototype, "Experimental",
      "Informational", and "Historic".  There are no time limits
      associated with these non-standard track labels, and the documents
      bearing these labels are not Internet standards in any sense.  As
      the Internet grows, there is a growing amount of credible
      technical work being submitted directly to the RFC Editor without
      having been gone through the IETF.  It is possible that such
      outside submissions may overlap or even conflict with ongoing IETF
      activities.  In order for the best technical result to emerge for
      the community, we believe that the such outside submissions should
      be given the opportunity to work within IETF to gain the broadest
      possible consensus.

      It is also possible that supporters of a view different from the
      IETF may wish to publish their divergent view.  For this reason,
      it is important that, ultimately, authors should have the
      opportunity to publish Informational and Experimental RFCs should



IAB - IESG                                                     [Page 15]

RFC 1602               Internet Standards Process             March 1994


      they wish to.  However, it is also possible that this could open a
      loophole in which developers could try to bypass the IETF
      consensus process completely by publishing an Informational RFC
      (and relying on the prestige of the RFC series to gain community
      support for their document).

      For all these reasons, the IESG and the RFC Editor have agreed to
      the following policy for publishing Info and Exp RFCs:

      1.   The RFC Editor will bring to the attention of the IESG all
           Informational and Experimental submissions that the RFC
           Editor feels may be related to, or of interest to, the IETF
           community.

      2.   The IESG will review all such referrals within a fixed length
           of time and make a recommendation on whether to publish, or
           to suggest that the author bring their work within the IETF.

      3.   If the IESG recommends that the work be brought within the
           IETF, but the author declines the invitation, the IESG may
           add disclaimer text into the standard boilerplate material
           added by the RFC Editor (e.g., "Status of this memo").

           2.4.1  Prototype

              For new protocols which affect core services of the
              Internet or for which the interactions with existing
              protocols are too complex to fully assimilate from the
              written specification, the IESG may request that
              operational experience be obtained prior to advancement to
              Proposed Standard status.  In these cases, the IESG will
              designate an otherwise complete specification as
              "Prototype". This status permits it to be published as an
              RFC before it is entered onto the standards track.  In
              this respect, "Prototype" is similar to "Experimental",
              except that it indicates the protocol is specifically