rfc1543.txt

RFC 的详细文档！

      RFCs in PostScript Format may be submitted to the RFC Editor in
      e-mail messages (or as online files).  If you plan to submit a
      document in PostScript please consult the RFC Editor first.

      Note that since the ASCII text version of the RFC is the primary
      version, the PostScript version must match the text version.  The
      RFC Editor must decide if the PostScript version is "the same as"
      the ASCII version before the PostScript version can be published.

4.  Headers and Footers

   There is the first page heading, the running headers, and the running
   footers.

   4a.  First Page

      Please see the front page of this memo for an example of the front
      page heading.  On the first page there is no running header.  The
      top of the first page has the following items:

      Network Working Group

         The traditional heading for the group that founded the RFC
         series.  This appears on the first line on the left hand side
         of the heading.

      Request for Comments: nnnn

         Identifies this as a request for comments and specifies the
         number.  Indicated on the second line on the left side.  The
         actual number is filled in at the last moment before
         publication by the RFC Editor.




Postel                                                          [Page 6]

RFC 1543              Instructions to RFC Authors           October 1993


      Author

         The author's name (first initial and last name only) indicated
         on the first line on the right side of the heading.

      Organization

         The author's organization, indicated on the second line on the
         right side.

      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.

      Category

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

      Title

         The title appears, centered, below the rest of the heading.

      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 a
      shortened 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 and the page number on the right ([Page N]).




Postel                                                          [Page 7]

RFC 1543              Instructions to RFC Authors           October 1993


5.  Status Section

   Each RFC must include on its first page the "Status of this Memo"
   section which contains a paragraph describing the type of the RFC.

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

   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."

   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.  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.

      Some example paragraphs are:

         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





Postel                                                          [Page 8]

RFC 1543              Instructions to RFC Authors           October 1993


            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.

7.  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.






Postel                                                          [Page 9]

RFC 1543              Instructions to RFC Authors           October 1993


8.  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.

9.  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 e-mail address.

10.  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 SUPERSEDES 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.

      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 OBSOLETE.



Postel                                                         [Page 10]

RFC 1543              Instructions to RFC Authors           October 1993


   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.

11.  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.

12.  Contact

   To contact the RFC Editor send an email message to