rfc2223.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页

      Date

         This is the Month and Year of the RFC Publication. Indicated on
         the third line on the right side.

      Updates or Obsoletes

         If this RFC Updates or Obsoletes another RFC, this is indicated
         as third line on the left side of the heading.








Postel & Reynolds            Informational                      [Page 7]

RFC 2223              Instructions to RFC Authors           October 1997


      Category

         The category of this RFC, one of: Standards Track, Best Current
         Practice, Informational, or Experimental.  This is indicated on
         the third (if there is no Updates or Obsoletes indication) or
         fourth line of the left side.

      Other Numbers

         Other numbers in the RFC series of notes include the subseries
         of FYI (For Your Information) [4], BCP (Best Current Practice)
         [5], and STD (Standard) [6].  These are placed on the left
         side.

      Title

         The title appears, centered, below the rest of the heading.
         Periods or "dots" in the titles are not allowed.

      If there are multiple authors and if the multiple authors are from
      multiple organizations the right side heading may have additional
      lines to accommodate them and to associate the authors with the
      organizations properly.

   4b.  Running Headers

      The running header in one line (on page 2 and all subsequent
      pages) has the RFC number on the left (RFC NNNN), the (possibly
      nshortened form) title centered, and the date (Month Year) on the
      right.

   4c.  Running Footers

      The running footer in one line (on all pages) has the author's
      last name on the left, category centered, and the page number on
      the right ([Page N]).

5.  Status Section

   Each RFC must include on its first page the "Status of this Memo"
   section which contains two elements: (1) a paragraph describing the
   type of the RFC, and (2) the distribution statement.

   The content of this section will be one of the four following
   statements.






Postel & Reynolds            Informational                      [Page 8]

RFC 2223              Instructions to RFC Authors           October 1997


   Standards Track

      "This document specifies an Internet standards track protocol for
      the Internet community, and requests discussion and suggestions
      for improvements.  Please refer to the current edition of the
      "Internet Official Protocol Standards" (STD 1) for the
      standardization state and status of this protocol.  Distribution
      of this memo is unlimited."

   Best Current Practice

      "This document specifies an Internet Best Current Practices for
      the Internet Community, and requests discussion and suggestions
      for improvements.  Distribution of this memo is unlimited."

   Experimental

      "This memo defines an Experimental Protocol for the Internet
      community.  This memo does not specify an Internet standard of any
      kind.  Discussion and suggestions for improvement are requested.
      Distribution of this memo is unlimited."

   Informational

      "This memo provides information for the Internet community.  This
      memo does not specify an Internet standard of any kind.
      Distribution of this memo is unlimited."

6.  Copyright Notice

   Immediately following the Status section the statement, "Copyright
   (C) The Internet Society (date).  All Rights Reserved." is placed.
   Also, see Section 11 for the full statement that must appear at the
   end of the document.

7.  Introduction Section

   Each RFC should have an Introduction section that (among other
   things) explains the motivation for the RFC and (if appropriate)
   describes the applicability of the protocol described.

      Normally, this will be the "abstract" section from the Internet
      Draft.  If the RFC is not based on an I-D, other possibilities
      are:







Postel & Reynolds            Informational                      [Page 9]

RFC 2223              Instructions to RFC Authors           October 1997


         Protocol

            This protocol is intended to provide the bla-bla service,
            and be used between clients and servers on host computers.
            Typically the clients are on workstation hosts and the
            servers on mainframe hosts.

            or

            This protocol is intended to provide the bla-bla service,
            and be used between special purpose units such as terminal
            servers or routers and a monitoring host.

         Discussion

            The purpose of this RFC is to focus discussion on particular
            problems in the Internet and possible methods of solution.
            No proposed solutions in this document are intended as
            standards for the Internet.  Rather, it is hoped that a
            general consensus will emerge as to the appropriate solution
            to such problems, leading eventually to the adoption of
            standards.

         Interest

            This RFC is being distributed to members of the Internet
            community in order to solicit their reactions to the
            proposals contained in it.  While the issues discussed may
            not be directly relevant to the research problems of the
            Internet, they may be interesting to a number of researchers
            and implementers.

         Status Report

            In response to the need for maintenance of current
            information about the status and progress of various
            projects in the Internet community, this RFC is issued for
            the benefit of community members.  The information contained
            in this document is accurate as of the date of publication,
            but is subject to change.  Subsequent RFCs will reflect such
            changes.

      These paragraphs need not be followed word for word, but the
      general intent of the RFC must be made clear.







Postel & Reynolds            Informational                     [Page 10]

RFC 2223              Instructions to RFC Authors           October 1997


8.  References Section

   Nearly all RFCs contain citations to other documents, and these are
   listed in a References section near the end of the RFC.  There are
   many styles for references, and the RFCs have one of their own.
   Please follow the reference style used in recent RFCs.  See the
   reference section of this RFC for an example.  Please note that for
   protocols that have been assigned STD numbers, the STD number must be
   included in the reference.

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  BCP 14, RFC 2119 [3], defines these words as they
   should be interpreted in IETF documents.

9.  Security Considerations Section

   All RFCs must contain a section near the end of the document that
   discusses the security considerations of the protocol or procedures
   that are the main topic of the RFC.

10.  Author's Address Section

   Each RFC must have at the very end a section giving the author's
   address, including the name and postal address, the telephone number,
   (optional: a FAX number) and the Internet email address.

11.  Copyright Section

   Per BCP 9, RFC 2026 [2], "The following copyright notice and
   disclaimer shall be included in all ISOC standards-related
   documentation."  The following statement should be placed on the last
   page of the RFC, as the "Full Copyright Statement".

      "Copyright (C) The Internet Society (date).  All Rights Reserved.

      This document and translations of it may be copied and furnished
      to others, and derivative works that comment on or otherwise
      explain it or assist in its implementation may be prepared, copied,
      published and distributed, in whole or in part, without
      restriction of any kind, provided that the above copyright notice
      and this paragraph are included on all such copies and derivative
      works.  However, this document itself may not be modified in any
      way, such as by removing the copyright notice or references to the
      Internet Society or other Internet organizations, except as needed
      for the purpose of developing Internet standards in which case the
      procedures for copyrights defined in the Internet Standards
      process must be followed, or as required to translate it into



Postel & Reynolds            Informational                     [Page 11]

RFC 2223              Instructions to RFC Authors           October 1997


      languages other than English.

      The limited permissions granted above are perpetual and will not
      be revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

12.  Relation to other RFCs

   Sometimes an RFC adds information on a topic discussed in a previous
   RFC or completely replaces an earlier RFC.  There are two terms used
   for these cases respectively, Updates and Obsoletes.  A document that
   obsoletes an earlier document can stand on its own.  A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

   Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.











Postel & Reynolds            Informational                     [Page 12]

RFC 2223              Instructions to RFC Authors           October 1997


      For example:

         On the Assigned Numbers RFCs the term Obsoletes should be used
         since the new document actually incorporate new information
         (however brief) into the text of existing information and is
         more up-to-date than the older document, and hence, replaces it
         and makes it Obsoletes.

   In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
   the following may be used with early documents to point to later
   documents.

   Obsoleted-by

      To be used to refer to the newer document(s) that replaces the
      older document.

   Updated-by

      To be used to refer to the newer section(s) which are to be added
      to the existing, still used, document.

13.  Protocol Standards Process

   See the current "Internet Official Protocol Standards" (STD 1) memo
   for the definitive statement on protocol standards and their
   publication [1].

   The established procedure is that when the IESG completes work on a
   document that is to become a standards track RFC the communication
   will be from the Secretary of the IESG to the RFC Editor.  Generally,
   the documents in question are Internet Drafts.  The communication
   usually cites the exact Internet Draft (by file name) in question.
   The RFC Editor must assume that only that file is to be processed to
   become the RFC.  If the authors have small corrections to the text,
   they should be sent to the RFC Editor separately (or as a "diff"), do
   not send a new version of the document.

14.  Contact

   To contact the RFC Editor send an email message to:

         "[e-mail]".








Postel & Reynolds            Informational                     [Page 13]

RFC 2223              Instructions to RFC Authors           October 1997


15.  Distribution Lists

   The RFC announcements are distributed via two mailing lists: the
   "IETF-Announce" list, and the "RFC-DIST" list.  You don't want to be
   on both lists.

   To join (or quit) the IETF-Announce list send a message to ietf-
   [e-mail].

   To join (or quit) the RFC-DIST list send a message to rfc-dist-
   [e-mail].

16.  RFC Index

   Several organizations maintain RFC Index files, generally using the
   file name "rfc-index.txt".  The contents of such a file copied from