rfc1310.txt

<VC++网络游戏建摸与实现>源代码

         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.

         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.  Furthermore, the IAB 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 in
         the Experimental state (see below), which is not part of the
         standards track, 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.  In some
         cases, the IESG may recommend that the requirements be
         explicitly reduced in order to allow a protocol to advance into



IAB                                                            [Page 12]

RFC 1310               Internet Standards Process             March 1992


         the Proposed Standard state.  This can happen if the
         specification is considered to be useful and necessary (and
         timely), even absent the missing features.  For example, some
         protocols have been advanced by explicitly deciding to omit
         security features at the Proposed Standard level, since an
         overall security architecture was still under development.

      3.2.2. Draft Standard

         A specification from which at least two independent and
         interoperable implementations have been developed, and for
         which adequate 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
         demonstrate unforeseen behavior when subjected to large-scale
         use in production environments.

      3.2.3. Standard

         A specification for which significant implementation and
         operational experience has been obtained may be elevated to the
         Standard level.  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.

   3.3. 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.  Such specifications are labeled with one of three
      "non-standards track" maturity levels: "Historic", "Experimental",
      and "Informational".

      3.3.1. Historic

         A TS or AS that has been superseded by a more recent
         specification or is for any other reason considered to be



IAB                                                            [Page 13]

RFC 1310               Internet Standards Process             March 1992


         obsolete is assigned to the "Historic" level.  (Purists have
         suggested that the word should be "Historical"; however, at
         this point the use of "Historic" is historical.)

      3.3.2. Experimental

         The "Experimental" designation on a TS permits widespread
         dissemination (through publication according to the procedures
         defined by this document) with explicit caveats:  it may
         specify behavior that has not been thoroughly analyzed or is
         poorly understood;  it may be subject to considerable change;
         it may never be a candidate for the formal standards track;
         and it may be discarded in favor of some other proposal.

         Any TS that is not an immediate candidate for Internet
         standardization is appropriate for publication as Experimental.
         Interested parties are thereby given the opportunity to gain
         experience with implementations and to report their findings to
         the community of interest, but the specification is explicitly
         not recommended for general production use.

      3.3.3. Informational

         An "Informational" specification is published for the general
         information of the Internet community, and does not represent
         an Internet community consensus or recommendation.

         Specifications that have been prepared outside of the Internet
         community and are not incorporated into the Internet standards
         process by any of the provisions of Section 4 may be published
         as Informational RFCs, with the permission of the owner.  Such
         a document is not an Internet Standard in any sense.

   3.4.  Requirement Levels

      An AS may apply one of the following "requirement levels" to each
      of the TSs to which it refers:

      (a)  Required:  Implementation of the referenced TS, as specified
           by the AS, is required to achieve minimal conformance.  For
           example, IP and ICMP must be implemented by all Internet
           systems using the TCP/IP Protocol Suite.

      (b)  Recommended:  Implementation of the referenced TS is not
           required for minimal conformance, but experience and/or
           generally accepted technical wisdom suggest its desirability
           in the domain of applicability of the AS.  Vendors are
           strongly encouraged to include the functions, features, and



IAB                                                            [Page 14]

RFC 1310               Internet Standards Process             March 1992


           protocols of Recommended TSs in their products, and should
           omit them only if the omission is justified by some special
           circumstance.

      (c)  Elective:  Implementation of the referenced TS is optional
           within the domain of applicability of the AS; that is, the AS
           creates no explicit necessity to apply the TS.  However, a
           particular vendor may decide to implement it, or a particular
           user may decide that it is a necessity in a specific
           environment.

      As noted in Section 2.5, there are TSs that are not in the
      standards track or that have been retired from the standards
      track, and are therefore not required, recommended, or elective.
      Two additional "requirement level" designations are available for
      such TSs:

      (d)  Limited Use:  The TS is considered appropriate for use only
           in limited or unique circumstances.  For example, the usage
           of a protocol with the "Experimental" designation should
           generally be limited to those actively involved with the
           experiment.

      (e)  Not Recommended:  A TS that is considered to be inappropriate
           for general use is labeled "Not Recommended".  This may be
           because of its limited functionality, specialized nature, or
           historic status.

      The "IAB Official Protocol Standards" RFC lists a general
      requirement level for each TS, using the nomenclature defined in
      this section.  In many cases, more detailed descriptions of the
      requirement levels of particular protocols and of individual
      features of the protocols will be found in appropriate ASs.

4.  EXTERNAL STANDARDS AND SPECIFICATIONS

   Many de facto and de jure standards groups other than the IAB/IETF
   create and publish standards documents for network protocols and
   services.  When these external specifications play an important role
   in the Internet, it is desirable to reach common agreements on their
   usage -- i.e., to establish Internet Standards relating to these
   external specifications.

   There are two categories of external specifications:

   (1)  Open Standards

        Accredited national and international standards bodies, such as



IAB                                                            [Page 15]

RFC 1310               Internet Standards Process             March 1992


        ANSI, ISO, IEEE, and CCITT, develop a variety of protocol and
        service specifications that are similar to Technical
        Specifications (see glossary in Appendix A).  These
        specifications are generally de jure standards.  Similarly,
        national and international groups publish "implementors'
        agreements" that are analogous to Applicability Statements,
        capturing a body of implementation-specific detail concerned
        with the practical application of their standards.

   (2)  Vendor Specifications

        A vendor-specific specification that has come to be widely used
        in the Internet may be treated by the Internet community as a de
        facto "standard".  Such a specification is not generally
        developed in an open fashion, is typically proprietary, and is
        controlled by the vendor or vendors that produced it.

   To avoid conflict between competing versions of a specification, the
   Internet community will not standardize a TS or AS that is simply an
   "Internet version" of an existing external specification, unless an
   explicit cooperative arrangement to do so has been made.  There are,
   however, several ways in which an external specification that is
   important for the operation and/or evolution of the Internet may be
   adopted for Internet use:

   (a)  Incorporation of an Open Standard

        An Internet Standard TS or AS may incorporate an open external
        standard by reference.  The reference must be to a specific
        version of the external standard, e.g., by publication date or
        by edition number, according to the prevailing convention of the
        organization that is responsible for the specification.

        For example, many Internet Standards incorporate by reference
        the ANSI standard character set "ASCII" [7].

   (b)  Incorporation of a Vendor Specification

        Vendor-proprietary specifications may also be incorporated, by
        reference to a specific version of the vendor standard.  If the
        vendor-proprietary specification is not widely and readily
        available, the IAB may request that it be published as an
        Informational RFC.

        In order for a vendor-proprietary specification to be
        incorporated within the Internet standards process, the
        proprietor must agree in writing to the IAB that "right to use"
        licenses will be available on a non-discriminatory basis and at



IAB                                                            [Page 16]

RFC 1310               Internet Standards Process             March 1992


        a reasonable cost.  See also Sections 5 and 6.

        In addition, the IAB/IETF will generally not favor a particular
        vendor's proprietary specification over the technically
        equivalent and competing specifications of other vendors by
        making it "required" or "recommended".

   (c)  Assumption

        An IETF Working Group may start with a vendor's (or other
        body's) voluntarily contributed specification, and independently
        evolve the specification into a TS or AS.  Here "independently"
        means that the IETF work is not constrained by conditions
        imposed by the owner of the original specification;  however,
        the continued participation of the original owner in the IETF
        work is likely to be valuable, and is encouraged.  The IAB must
        receive a formal delegation of responsibility from the original
        owner that gives the IAB/IETF responsibility for evolution of
        the specification.

   As provided by section 3.1.2, an AS that specifies how an external
   technical specification should be applied in the Internet,
   incorporating the external specification by reference, may become an
   Internet Standard.

5.  INTELLECTUAL PROPERTY RIGHTS

   Prior to the approval of a specification as a Proposed Standard, all
   interested parties are required to disclose to the IAB the existence
   of any intellectual property right claims known to them that might
   apply to any aspect of the Proposed Standard.

   This requirement refers specifically to disclosure of the *existence*
   of a current or anticipated claim of an intellectual property right,
   not the details of the asserted right itself.

6.  PATENT POLICY

   This section is tentative, subject to legal review.

   There is no objection in principle to drafting an Internet Standard
   in terms that include an item or items subject to patent rights that
   may have been asserted in one or more countries, if it is considered
   that technical reasons justify this approach.  In such cases the
   procedure described in this section shall be followed.






IAB                                                            [Page 17]

RFC 1310               Internet Standards Process             March 1992


   6.1 Statement from Patent Holder

      Prior to approval of the specification as a Proposed Standard, the
      IAB shall receive from the known patent holders, in a form
      acceptable to and approved by the IAB, either (a) assurance in the
      form of a general disclaimer to the effect that the patent holder
      does not hold and does not anticipate holding any right that would
      be violated as a consequence of conformance to the standard, or
      (b) assurance that

      (1)  a license will be made available without compensation to all