[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2223) 00 01 02 03 04 05 06 07 08

INTERNET-DRAFT                                      J. Reynolds, Editor
draft-rfc-editor-rfc2223bis-03.txt                    R. Braden, Editor
Obsoletes: 2223                                              RFC Editor
Category: Informational                                 12 October 2002
Expires: April 2003

           Instructions to Request for Comments (RFC) Authors

                              ** DRAFT **

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
              http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
              http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo provides instructions for authors of Request for Comments
   (RFC) documents.  It specifies formatting requirements and editorial
   policies, addresses frequently asked questions, and serves as a
   model for constructing a properly formatted RFC.










RFC Editor                   Informational                      [Page 1]


Internet-Draft        Instructions to RFC Authors          23 April 2002


Table of Contents

   1. Introduction ..................................................  3
      1.1 The RFC Document Series ...................................  3
      1.2 The RFC Editor ............................................  3
      1.3 The RFC Publication Process ...............................  4
   2.  RFC Editorial and Publication Policies .......................  6
      2.1 Immutability ..............................................  7
      2.2 Not all RFCs are Standards ................................  7
      2.3 Publication Language ......................................  7
      2.4 Publication Format(s) .....................................  7
      2.5 Consistent Document Style .................................  8
      2.6 Assignment of RFC Numbers .................................  8
      2.7 Normative References ......................................  9
      2.8 URLs in RFCs .............................................. 10
      2.9 Titles .................................................... 10
      2.10 IANA Considerations ...................................... 11
      2.11 Relation to Other RFCs ................................... 11
      2.12 Author Lists ............................................. 12
      2.13 April 1 RFCs ............................................. 11
   3. General Format Rules for RFCs ................................. 11
      3.1 General ASCII Format Rules ................................ 11
      3.2 Postscript Format Rules ................................... 14
      3.3 Header and Footer Formats ................................. 15
      3.4 Protocol Data Definitions ................................. 15
   4.  Required Sections in an RFC .................................. 16
   5. RFC Information and Contacts .................................. 22
   6. Acknowledgments ............................................... 23
   Appendix A - RFC Boilerplate ..................................... 28
   Appendix B - RFC Preparation Tools ............................... 29
   Appendix C - Checklist ........................................... 30
   Appendix D - Changes from RFC 2223 ............................... 32
   Normative References ............................................. 33
   Informative References ........................................... 33
   Security Considerations .......................................... 34
   Authors' Addresses ............................................... 34
   Full Copyright Statement ......................................... 35














RFC Editor                   Informational                      [Page 2]


Internet-Draft        Instructions to RFC Authors          23 April 2002


Changes from -02 version


   1.   Removed old Appendix C (definition of ASCII) and replace it with
        a reference to RFC 20 [11].


   2    Added new Appendix C, a Checklist.


   3    Made a few editorial changes and typo fixes.


   4    Clarified that .txt.pdf versions are equally authoritative with
        .txt versions of RFCs.


   5    Stated policy that (nearly) all abbreviations in body of the
        document must be expanded when first encountered.


Changes from -01 version


   1.   Incorporated new author list guidelines.

   2.   Clarified rules for hyphenation (Section 3.1 (6)).

   3.   Added guideline on example URLs (Section 2.8).

   4.   Clarified that dangling normative references are strictly prohi-
        bited only for standards-track documents (Section 2.7).



















RFC Editor                   Informational                      [Page 3]


Internet-Draft        Instructions to RFC Authors          23 April 2002


1.  Introduction

   This Request for Comments (RFC) document provides instructions for
   authors regarding the preparation of RFCs and describes RFC
   publication policies.

   1.1 The RFC Document Series

      The Requests for Comments documents, commonly known as RFCs, form
      a series of more than 3000 memos about computer communication and
      packet switching networks.  The official specification documents
      of the Internet protocol suite are defined by the Internet
      Engineering Task Force (IETF) and the Internet Engineering
      Steering Group (IESG).  These specifications are recorded and
      published as standards track RFCs (described in a later section
      and in RFC 2026).  As a result, the RFC publication process plays
      an important role in the Internet standards process.

      The RFC series was started in 1969 as a set of technical and
      organizational notes of the ARPAnet research community [1].  Since
      the early 1980s, the series has focused on the development of the
      Internet and the TCP/IP protocol suite.  Memos in the RFC series
      discuss many aspects of networking, including protocols,
      procedures, programs, and concepts as well as meeting notes,
      opinions, and sometimes humor.  For more information on the
      history of the RFC series, see RFC 2555, "30 Years of RFCs" [1].

      The RFC numbers provide a single unique address space for locating
      a particular RFC.  It has proven useful to define specific subsets
      or "sub-series" of the RFCs by attaching a secondary index.  There
      are three secondary indexes in use:  -- FYI (For Your Information)
      [4], BCP (Best Current Practice) [5], and STD (Standard) [6].

   1.2 The RFC Editor

      The RFC series is published by the RFC Editor, an organization
      that is funded by the Internet Society (ISOC) and is a project at
      the Information Sciences Institute of the University of Southern
      California (USC/ISI).

      The RFC Editor is responsible for the final editorial review and
      the publication of RFCs.  The RFC Editor also maintains the
      official RFC archive and the master index file, which are
      accessible via the Web, FTP, and email (see URL in Section 5.)







RFC Editor                   Informational                      [Page 4]


Internet-Draft        Instructions to RFC Authors          23 April 2002


   1.3 The RFC Publication Process

      A more complete explanation of the RFC publication procedures will
      be found in RFC 2026 [2].

      1.3.1 RFC Submission

         The procedure for submitting a document for publication as an
         RFC differs slightly depending upon the document's source.
         Submissions come from the IETF or from an individual.

         Before the RFC Editor considers publication of a document, it
         must first be submitted as an Internet-Draft (I-D) [1].  All
         RFCs have been I-Ds, but not all I-Ds become RFCs.

         o Submission from the IETF

            RFCs most often originate in the IETF and are submitted to
            the RFC Editor from the Internet Engineering Steering Group
            (IESG).  These submissions are transmitted via official
            messages that are recorded at the IETF web site.  An IESG
            submission may have any of these status values:  Proposed
            Standard, Draft Standard, Standard (sometimes referred to as
            "Full Standard"), BCP (Best Common Practice), Experimental,
            or Informational, as determined by the IESG.  A document
            with Proposed Standard, Draft Standard, or Standard status
            is said to be a standards-track document [2].

            IETF RFCs normally originate in working groups.  However,
            there are individual submissions to the IESG that have been
            accepted into the IETF process.

         o Individual Submission

            Individuals can also submit Internet-Drafts directly to the
            RFC Editor for publication as RFCs.  Such individual
            submissions may have Experimental or Informational status.
            The choice is determined by the author with the agreement of
            the IESG (see below).

            Once the document has been posted as an Internet-Draft, the
            author should contact rfc-editor@rfc-editor.org and request
            that the document be reviewed for publication as an
            Informational or Experimental RFC (please specify which).
            The RFC Editor does not accept independent submissions of
            standards track documents; all standards track documents
            must be submitted to the appropriate area directors of the
            IETF.



RFC Editor                   Informational                      [Page 5]


Internet-Draft        Instructions to RFC Authors          23 April 2002


         Since Internet-Drafts are precursors to RFCs, the rules for
         formatting Internet-Drafts are consistent with the RFC
         formatting rules presented below.  Specific Internet-Draft
         guidelines are available from the IETF web page.  The Internet
         Draft must include boilerplate that allows RFC publication (see
         "Guidelines to Authors of Internet-Drafts" [10]).

         If the author has used nroff to prepare the Internet-Draft, it
         is helpful to make this available to the RFC Editor.  If there
         is a Postscript and/or PDF version of the document, the author
         should inform the RFC Editor at the time of submission of the
         ASCII version.

      1.3.2 RFC Review

         Memos intended to become RFCs must first be published as
         Internet-Drafts.  This allows feedback from members of the
         Internet community and the IESG.

         The IESG reviews IETF RFC submissions for quality and
         conformance with IETF procedures.  The IESG also reviews
         individual submissions to ensure they do not conflict with work
         in progress in the IETF and to ensure technical quality.  When
         the topic of an individual submission is closely related to an
         existing IETF Working Group, the IESG may request that the
         author coordinate with the working group.  This may result in
         the production of a revised memo as a working group Internet-
         Draft, which will eventually emerge from the IETF process as a
         publication recommendation from the IESG to the RFC Editor.

         The IESG may suggest improvements to the author of the document
         prior to publication.  It may be determined that the submitted
         document is not appropriate material for publication as an RFC.
         In some cases the IESG will agree to the publication with the
         addition of an "IESG Position" statement in the document that
         defines a limited context within which the specification is
         valid, to prevent its misuse.

         The RFC Editor will publish all documents submitted from the
         IESG but reserves the right to discuss with the IESG issues
         about particular documents.  The RFC Editor makes the final
         decision about individual submission publications.

      1.3.3 Publication

         A document that is submitted to the RFC Editor enters the RFC
         Editor's queue.  The queue is publicly accessible at the RFC
         Editor Web site (Section 5).  The RFC remains in the queue



RFC Editor                   Informational                      [Page 6]


Internet-Draft        Instructions to RFC Authors          23 April 2002


         until it is published, or until the IESG or the author requests
         that it be removed.

         The RFC Editor ensures that the document follows the rules
         described in this document.  The RFC Editor may make editorial
         changes to clarify readability and to provide a uniform style
         and format.  If significant changes are required to satisfy the
         rules and/or to bring the RFC up to publication quality, the
         memo will often be returned to the author for the additional
         work.

         When editing of the document is complete, the RFC Editor will
         send the result to the authors for careful proof-reading.  This
         quality control step is critical to maintaining the quality of
         RFCs.  Although this process is traditionally called the
         "Authors' 48 Hours" period, the RFC Editor is always willing to
         give authors reasonable additional time to review the document,
         and the document will not be published until all listed authors
         agree.  While it is helpful to have one principal author during
         the editing process, all listed authors will be considered
         responsible for the correctness of the final document.

         In practice, the editorial process among the IESG, the RFC
         Editor, and the author(s) can be lengthy and convoluted, and
         the time spent in the RFC Editor's queue can vary greatly.
         Problems found by either group often result in document
         revisions by the authors.  These revisions may require the
         publication of another Internet-Draft, and the result must be
         re-reviewed.  Publication may be held up awaiting Internet
         Assigned Numbers Authority (IANA) assignments, or in order to
         synchronize publication with that of related RFCs.

2.  RFC Editorial and Publication Policies

   This section summarizes some general policies governing the
   publication of RFCs.  Individual policies may be modified or new
   policies added by the RFC Editor and the IESG, before the present
   document is revised.  RFC authors should obtain the latest policy
   statements (see "News") from the RFC Editor web page.

   2.1 Immutability

      Since the RFCs form an archival series, an RFC cannot be altered
      once it is published.  To change the contents of an RFC, a new RFC
      must be written that obsoletes the previous one.  (Early in the
      history of RFCs, the Editor did occasionally make small editorial
      changes after publication, but this led to confusion regarding
      which version was correct, and it was a slippery slope.  To avoid



RFC Editor                   Informational                      [Page 7]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      these pitfalls, the never-change rule is now strictly enforced.)

      Although RFCs are subjected to careful scrutiny by the RFC Editor
      and the authors before publication, errors do sometimes creep in.
      For this reason, the RFC Editor stongly recommends that the
      authors thoroughly review the document during the "authors' 48
      hours" period.

      The RFC Editor maintains an online list of errata for existing
      RFCs.  If you find what you believe to be an error in an RFC,
      consult the errata page at the RFC Editor web site.  If the bug is
      not listed, please send e-mail to the authors of the document, and
      cc: the RFC Editor at: rfc-editor@rfc-editor.org.

   2.2 Not all RFCs are Standards

      Eager salesmen have been known to imply that all RFCs represent
      official Internet standards.  This is completely false and
      misleading.  While some RFCs are standards track documents, many
      have the status of Informational or Experimental and do not
      represent a standard of any kind.  Even those documents on the
      standards track come in three grades -- Proposed Standard, Draft
      Standard, and Standard -- and only the last is a full standard.

   2.3 Publication Language

      Like the Internet itself, the IETF and the Internet Society are
      international organizations with representation from all areas of
      the world.  However, English is the primary language in which IETF
      business is conducted, and English is the official publication
      language for RFCs.

      RFCs submitted for publication are required to meet a reasonable
      standard for clear and correct English.

      RFC 2026 specifically allows RFCs to be translated into languages
      other than English.  Repositories may exist for RFCs that have
      been translated into particular languages. This is highly
      desirable and useful.  However, it is not possible for the RFC
      Editor to certify that such translations are accurate.  Therefore,
      the function of the RFC Editor, with respect to non-English RFCs,
      is limited to providing pointers to non-English language RFC
      repositories.  Upon request, the RFC Editor will list any such
      repository on its Web page.

   2.4 Publication Format(s)

      RFCs are published as ASCII text (.txt) files.  However, secondary



RFC Editor                   Informational                      [Page 8]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      or alternative versions of an RFC may be provided in PostScript
      and/or PDF, to allow the inclusion of fancy diagrams and graphs
      that cannot possibly be rendered in ASCII.

           The continued use of ASCII text for RFCs, despite the spread
           of "more modern" printing formats, is intermittently debated
           by the Internet community.  The consensus continues to be
           that the great advantages of plain ASCII text -- the ability
           to readily edit, cut-and-paste, and search documents, as well
           as the ubiquitous availability of tools for these functions
           -- have made the ASCII choice a clear winner.

      The ASCII text version is always the official specification, and
      it must adequately and completely define the technical content.
      (A very few exceptions have been made over the 30 year history of
      RFCs, allowing a definitive .ps version with no .txt version.)
      The primacy of the ASCII version typically requires that the
      critical diagrams and packet formats be rendered as "ASCII art" in
      the .txt version.

      For the convenience of those whose operating systems have
      difficulty supporting simple ASCII text, the RFC Editor also
      maintains PDF files that are exact facsimiles of the ASCII (.txt)
      versions.  These PDF files, with suffix .txt.pdf, are equally
      authoritative with the .txt versions.

      Postscript and PDF versions suffer from a serious flaw: the RFC
      Editor cannot easily make editorial changes in the source file to
      produce a new document in either of these formats.  This makes the
      editorial process somewhat painful for both the author and editor.
      When a .ps (or .pdf) version is submitted with a .txt version, the
      RFC Editor will first edit the .txt version.  The final form of
      the .txt version (or, when feasible, the diffs) will be returned
      to the author.  The author must then update the .ps/.pdf files to
      match, as closely as possible, the content and format of the ASCII
      .txt file.  When the RFC Editor agrees that the .ps/.pdf versions
      are acceptable, they will be published simultaneously.

   2.5 Consistent Document Style

      The RFC Editor attempts to enforce a consistent style of RFCs.  To
      do this, the RFC Editor may choose to reformat a submitted RFC or
      ask the author to reformat it.  Effort is minimized when the
      submitted document matches the style of the most recent RFCs.
      Please read the rules and recommendations that are presented in
      following sections of this memo and look at some recent RFCs, to
      adopt an appropriate style.




RFC Editor                   Informational                      [Page 9]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      To format most ASCII RFCs for publication, the RFC Editor uses the
      unix "nroff" program with a very simple set of the formatting
      commands (or "requests") from the "ms" macro package (see Appendix
      B).  If a memo submitted to be an RFC has been prepared by the
      author using nroff, it is helpful to make the nroff source
      available when the document is submitted.

      When a .ps version is published, the RFC Editor will also publish
      a corresponding .pdf version by using the 'distill' utility.

   2.6 Assignment of RFC Numbers

      RFC numbers are not assigned until very late in the editorial
      process to avoid gaps in the RFC number series.  Requests for
      early assignment of an RFC number for use in another forum are
      generally denied unless they originate from the IAB (Internet
      Architecture Board) or the IESG.

   2.7 Normative References

      Within an RFC, references to other documents fall into two general
      categories: "normative" and "informative".  Normative references
      specify documents that must be read to understand or implement the
      technology in the new RFC, or whose technology must be present for
      the technology in the new RFC to work.  An informative reference
      is not normative; rather, it only provides additional information.
      For example, an informative reference might provide background or
      historical information.  Material in an informative reference is
      not required to implement the technology in the RFC.

      The distinction between normative and informative references is
      often important.  The IETF standards process and the RFC Editor
      publication process need to know whether a reference to a work in
      progress is normative.  A standards-track RFC cannot be published
      until all of the documents that it lists as normative references
      have been published.  In practice, this often results in the
      simultaneous publication of a group of inter-related RFCs.

      An RFC must include separate lists of normative and informative
      references (see Section 4.8 below.)

   2.8 URLs in RFCs

      The use of URLs in RFCs is discouraged, because many URLs are not
      stable references.  Exceptions may be made for normative
      references in those cases where the URL is demonstrably the most
      stable reference available.  References to long-lived files on
      ietf.org and rfc-editor.org are also acceptable.



RFC Editor                   Informational                     [Page 10]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      RFCs that include URLs as generic examples must be careful to use
      the particular example URLs defined in RFC 2606, "Reserved Top-
      Level DNS Names" [10], to avoid accidental conflicts with real
      URLs.

   2.9 Titles

      Choosing a good title for an RFC can be a challenge.  A good title
      should fairly represent the scope and purpose of the document
      without being either too general or too specific.

      Abbreviations (e.g., acronyms) in a title should generally be
      expanded; the exception is abbreviations that are so common (like
      TCP, IP, SNMP, FTP, etc.) that every member of the IETF can be
      expected to recognize them immediately.  It is often helpful to
      follow the expansion with the parenthesized abbreviation.

           "Encoding Rules for the Common Routing Encapsulation
           Extension Protocol (CREEP)"

      Authors should be aware that the title of an RFC may be subject to
      policy considerations in addition to the requirement that it
      provide a concise and technically sound summary of the document
      contents.  For example, at various times in the history of the
      IETF, the words "Requirements" and "Policies" as well as the
      phrase "The Directory" have been banned from RFC titles, each for
      its own reason.

      RFCs that document a particular company's private protocol must
      bear a title of the form "XXX's ... Protocol" (where XXX is a
      company name), to clearly differentiate it from an IETF product.

   2.10 IANA Considerations

      Many RFCs define protocol specifications that require the
      assignment of values to protocol parameters, and some define new
      parameter fields.  Assignment of these parameter values is often
      (and sometimes must be) deferred until publication of the defining
      RFC.  The IANA and the RFC Editor collaborate closely to ensure
      that all required parameters are assigned and entered into the
      final RFC text.

      Any RFC that defines a new "namespace" [9] of assigned numbers
      should include an IANA Considerations section specifying how that
      space should be administered.  See "Guidelines for Writing an IANA
      Considerations Section in RFCs" [9] for a detailed discussion of
      the issues to be considered and the contents of this section.




RFC Editor                   Informational                     [Page 11]


Internet-Draft        Instructions to RFC Authors          23 April 2002


   2.11 Relation to other RFCs

      Sometimes an RFC adds information on a topic discussed in a
      previous RFC or completely replaces an earlier RFC.  Two terms are
      used for these cases: Updates and Obsoletes, respectively.

         Updates

            Specifies an earlier document whose contents are modified or
            augmented by the new document.  The new document cannot be
            used alone, it can only be used in conjunction with the
            earlier document.

         Obsoletes

            Specifies an earlier document that is replaced by the new
            document.  The new document can be used alone as a
            replacement for the obsoleted document.  The new document
            may contain revised information or all of the same
            information plus some new information, however extensive or
            brief that new information may be.

      In lists of RFCs and in the RFC-Index (but not on the RFCs
      themselves) the following are used for older documents that were
      referred to by Obsoletes or Updates relations in newer documents:

         Obsoleted-by

            Used to specify newer document(s) that replace the older
            document.

         Updated-by

            Used to specify newer document(s) that modify or augment the
            older document.

   2.12 Authors Listed on RFC

      The IESG and IETF have ratified a policy of limiting the number of
      authors listed in the first page header of an RFC.  The specific
      policy is as follows.


      (1)  A small set of author names, with affiliations, may appear on
           the front page header.  These should be the lead author(s)
           who are most responsible for the actual text.  When there are
           many contributors, the best choice will be to list the person
           or (few) persons who acted as document editor(s) (e.g.,"Tom



RFC Editor                   Informational                     [Page 12]


Internet-Draft        Instructions to RFC Authors          23 April 2002


           Smith, Editor").

           There is no rigid limit on the size of this set, but there is
           likely to be a discussion if the set exceeds five authors, in
           which case the right answer is probably to list one editor.

           The RFC Editor will hold all the people listed on the front
           page equally responsible for the final form and content of
           the published RFC.  In particular, the "Author's 48 Hours"
           final approval period will require signoff from all listed
           authors.

      (2)  An RFC may include a Contributors section, listing those
           contributors who deserve significant credit for the document
           contents.  The Contributors section is intended to provide a
           level of recognition greater than an acknowledgment and
           nearly equal to listing on the front page.  The choice of
           either, both, or none of Contributor and Acknowledgment
           sections in a particular RFC depends upon the circumstance.

      (3)  The body of an RFC may include an Acknowledgements section,
           in addition to or instead of a Contributors section.  An
           Acknowledgments section may be lengthy, and it may explain
           scope and nature of contributions.  It may also specify
           affiliations.

      (4)  The Authors' Address section at the end of the RFC must
           include the authors listed in the front page header.  The
           purpose of this section is to (1) unambiguously define
           author/contributor identity (e.g., the John Smith who works
           for FooBar Systems) and to (2) provide contact information
           for future readers who have questions or comments.

           At the discretion of the author(s), contact addresses may
           also be included in the Contributors section for those
           contributors whose knowledge makes them useful future
           contacts for information about the RFC.

      (5)  The RFC Editor may grant exceptions to these guidelines upon
           specific IESG request or in other exceptional circumstances.


   2.13 April 1 RFCs

      Many years ago the RFC Editor established the practice of
      publishing one or more satire documents on April 1 of each year.
      Readers should be aware that many of the RFCs bearing the date
      April 1 are not to be taken seriously.  The RFC Editor reviews



RFC Editor                   Informational                     [Page 13]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      April 1 RFC submissions for cleverness, humor, and topical
      association with computer networking, and a few of the best are
      published.  Submissions must be made to the RFC Editor in time for
      review and publication.

      Note that in past years the RFC Editor has sometimes published
      serious documents with April 1 dates.  Readers who cannot
      distinguish satire by reading the text may have a future in
      marketing.

3. General Format Rules for RFCs

   The following formatting rules are intentionally incomplete in some
   details.  They attempt to define only what is strictly necessary for
   uniformity and simplicity (a virtue).  Some latitude is allowed to
   accommodate a broad range of printers, systems, and evolving
   requirements.  The general objective is to create a series of
   documents that are reasonably uniform and are easy to read, while
   accommodating a wide range of content.

   3.1  General ASCII Format Rules

       (1) Character code

           The character code is US-ASCII [11] (also known as ISO
           464.IRV).  Only the printable ASCII characters and the three
           control characters CR, LF, and FF are allowed.

                Notes: CR and LF must be used only as provided in rule
                (2), and LF must be used only as provided in rule (3).
                Tab (HT) characters and Backspace (BS) characters are
                never allowed (hence there can be no underlining; see
                (4) below).

       (2) Width

           Each line must be limited to 72 characters followed by the
           character sequence that denotes an end-of-line (EOL).  This
           limit includes any left-side indentation.

                Note: An ASCII RFC is expected to be stored on a file
                disk using the EOL sequence of that system.  For
                example, MS DOS-based systems use the two-character
                sequence CR LF (Carriage Return followed by Line Feed),
                Unix systems use the single character LF for EOL, and
                EBCDIC systems use the single character NL (New Line).

                Whenever an RFC is transmitted across the Internet,



RFC Editor                   Informational                     [Page 14]


Internet-Draft        Instructions to RFC Authors          23 April 2002


                Internet protocol convention requires that each line of
                text be followed by the two-character EOL sequence CR LF
                (Carriage Return followed by Line Feed).  A user level
                protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
                the appropriate EOL transformation at each line end.
                Note that binary transmission of ASCII RFC files can
                cause the sender's EOL convention to "leak" into the
                receiver, causing confusion.

       (3) Height

           Each page must be limited to 58 lines followed by a Form Feed
           (FF) character, followed by an EOL sequence.  The 58 line
           limit includes the headers and footers specified below.

           All pages, except perhaps the first and last, should have the
           same number of lines when headers and footers are included.
           That is, footers should not "bounce" from page to page.

                Note: The maximum line count includes blank lines.
                However, the first line will normally be the first
                header line and the last line will be the final footer
                line; that is, it will not begin or end with a blank
                line.

                Note: 58 lines is the maximum; 55 is more commonly used
                and may actually produce more readable formatting.  The
                recommended page formatting parameters (see Appendix B)
                produce 55 line pages on many printers, for example.

                Note: The effect of the Height rule is that the
                following character sequence will be used:

                  <Last non-blank line of page p> <EOL> FF <EOL>

                                  <First line of page p+1> <EOL> ...

                As transmitted across the Internet as ASCII text, the
                character sequence is:

                  <Last non-blank line of page p> CR LF FF CR LF

                                  <First line of page p+1> CR LF ...

                Finally, note that the sequence FF CR LF has an
                ambiguous effect: on some printers, the FF implies an
                EOL, so this may produce a blank line; on other printers
                it will produce no blank line.  The number 58 and this



RFC Editor                   Informational                     [Page 15]


Internet-Draft        Instructions to RFC Authors          23 April 2002


                sequence were designed to render this ambiguity
                unimportant, assuming the (once predominant) printer
                standard of 60 lines per page.

       (4) No Overstriking

           No overstriking (or underlining) is allowed.

       (5) No Filling

           Do not fill the text with extra spaces to provide a straight
           right margin.  Do not right justify the text.

       (6) No Hyphenation

           Do not use hypenation at the right margin to split existing
           words.  However, hyphenated word sequences (e.g., "Internet-
           Draft") may be split at the hyphen across successive lines.

                Note: There are good reasons why the right page margin
                is required to be "ragged", and why hyphenation of words
                at the right margin is prohibited.  Studies have shown
                that text is harder to read when fixed-size spaces are
                inserted to adjust the right margins, regardless of
                which font is used or how smoothly the blank filler is
                inserted.  In addition, when technical text in a fixed-
                width font is hyphenated at the right margin, the
                printed result is not only less readable but also ugly.

       (7) Spaces at the End of a Sentence

           When a sentence ended by a period is immediately followed by
           another sentence, there should be two blank spaces after the
           period.  This rule provides clarity when an RFC is displayed
           or printed with a fixed-width font.

       (8) Footnotes

           Do not use footnotes.  If such notes are necessary, put them
           at the end of a section, or at the end of the document.

       (9) Line Spacing

           Use single-spaced text within a paragraph, and one blank line
           between paragraphs.






RFC Editor                   Informational                     [Page 16]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      (10) Page Numbering

           Pages must be numbered consecutively, starting from 1 on the
           first (cover) page.















































RFC Editor                   Informational                     [Page 17]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      (11) Headers and Footers

           RFCs must have running headers and footers, as defined below
           in Section 3.3.  The headers and footers must be separated
           from the body by at least one and preferably two blank lines.

      (12) Indentation

           Successive indentation of sub-subsections (as in this
           document, for example) is recommended but not required.
           Experience has shown that indentation by multiples of 3
           columns works well.  In any case, the careful use of
           indentation can make a very great improvement in the
           readability of a document.

   3.2  PostScript Format Rules

      (1p) Standard page size is 8 1/2 by 11 inches.

      (2p) Leave a margin of 1 inch on all sides (top, bottom, left, and
           right).

      (3p) Main text should have a point size of no less than 10 points
           with a line spacing of 12 points.

      (4p) Footnotes and graph notations no smaller than 8 points with a
           line spacing of 9.6 points.

      (5p) Three fonts are acceptable: Helvetica, Times Roman, and
           Courier, plus their bold-face and italic versions.  These are
           the three standard fonts on most PostScript printers.

      (6p) Prepare diagrams and images based on lowest common
           denominator PostScript.  Consider common PostScript printer
           functionality and memory requirements.

      (7p) The following PostScript commands should not be used:
           initgraphics, erasepage, copypage, grestoreall, initmatrix,
           initclip, banddevice, framedevice, nulldevice or renderbands.

           Note that the number of pages in a document and the page
           numbers on which various sections fall will likely differ
           between the ASCII and the PostScript versions of an RFC.
           Thus, cross references in the text by section number usually
           are easier to keep consistent than cross references by page
           number.





RFC Editor                   Informational                     [Page 18]


Internet-Draft        Instructions to RFC Authors          23 April 2002


   3.3  Header and Footer Formats

      RFCs must include running headers and footers that obey the
      following rules.

      o 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 title
         (possibly shortened) in the center, and the publication date
         (Month Year) on the right.

      o Running Footers

         All pages contain a one-line running footer, with the author's
         last name on the left, the category centered, and the page
         number on the right ([Page nn]).

         If there are two authors, the form "name & name" may be used;
         for more than two authors, use the form "name, et al."

   3.4  Protocol Data Definitions

      Many years ago, the RFC series adopted a pictorial approach to
      representing data structures such as protocol headers.
      Furthermore, the research community adopted a "big-endian"
      convention in which the bits and bytes are shown in network byte
      order, byte zero is the first byte shown, and bit zero is the most
      significant bit in a word or a field [8].

      For example, RFC 791 contains the following definition of the IP
      header format.  We strongly recommend that a new RFC follow the
      same formatting conventions, which have been found to work well.


















RFC Editor                   Informational                     [Page 19]


Internet-Draft        Instructions to RFC Authors          23 April 2002


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|  IHL  |Type of Service|          Total Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Identification        |Flags|      Fragment Offset    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to Live |    Protocol   |         Header Checksum       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options                    |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Example Internet Datagram Header

4.  Sections in an RFC

   An RFC may contain the following sections.  Some of these are
   optional, but if they are present they must be in this order (except
   where noted).

      1.  First-page header
      2.  Status of this Memo
      3.  Copyright Notice
      4.  IESG Note
      5.  Abstract
      6.  Table of Contents
      7.  Body of memo
      8.  References
      9.  Security Considerations
      10. IANA Considerations
      11. Contributors
      12. Acknowledgments
      13. Authors' Address
      14. Full Copyright Statement

   The rules for each of these sections are described below in
   corresponding subsections.

   The Body of the memo will normally contain section numbers.  Sections
   preceding the Body must not have section numbers; section numbers are
   optional for sections following the Body.






RFC Editor                   Informational                     [Page 20]


Internet-Draft        Instructions to RFC Authors          23 April 2002


   4.1.  First-Page Header

      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 left justified:

      "Network Working Group"

         This traditional title must be left-justified on the first line
         of the heading.  It denoted the ARPANET research group that
         founded the RFC series.

      "Request for Comments: nnnn"

         Identifies this as an RFC and specifies the number, left-
         justified on the second line.  The actual number is filled in
         at the last moment prior to publication by the RFC Editor.

      "BCP: nn" or
      "FYI: nn" or
      "STD: nn"

         One of these optional left-justified items indicates the sub-
         series number, if the RFC is a member of a sub-series.

      "Updates: nnnn" or "Updates: nnnn, ..., nnnn"

         Optional left-justified field, containing an RFC number or a
         comma-separated list of RFC numbers that are updated by this
         RFC.  See Section 5.

      "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"

         Optional left-justified field, containing an RFC number or a
         comma-separated list of RFC numbers that are obsoleted by this
         RFC.  See Section 5.

      "Category: xxxxxxxxx"

         Required left-justified field specifying the category (i.e.,
         status) of this RFC.  Here xxxxxxxx, the document status (see
         RFC 2026 [2]), may be one of:  Standards Track, Best Current
         Practice, Informational, or Experimental.

         The "Standards Track" category indicates that the status is one
         of: Proposed Standard, Draft Standard, or Standard.  The actual
         status may be found in STD 1, "Official Internet Standards", or
         from the RFC Editor web site.



RFC Editor                   Informational                     [Page 21]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      The following information appears right-justified in the header:

      Author

         The author's name (first initial and last name only), right-
         justified on the first line of the heading.

      Organization

         The author's organization, indicated on the line following the
         Author name.

         For multiple authors, each author name appears right-justified
         on its own line, followed by that author's organization.  When
         more than one author has the same organization, the
         organization can be "factored out" and appear only once
         following the corresponding Author lines.  However, such
         factoring is not necessary if it results in an unacceptable
         reordering of author lines.

         The total number of authors is generally limited; see Section
         2.12.

      Date

         The month and year of the RFC Publication, right-justified on
         the line after the last Organization line.

      The title appears, centered, below the rest of the heading,
      preceded and followed by at least one blank line.  Periods
      ("dots") are not allowed in the title.

      The title should be carefully chosen to accurately reflect the
      contents of the document.  See also Section 2.9.

   4.2. Status of this Memo

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

      The required contents of this section will be found in Appendix A.

   4.3  Copyright Notice







RFC Editor                   Informational                     [Page 22]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      The Copyright Notice section consists of the statement, "Copyright
      (C) The Internet Society (date).  All Rights Reserved." and is
      required.  The Full Copyright Statement described in Section 4.12
      must also appear at the end of the document.

   4.4  IESG Note

      This optional section will appear only when the IESG requires and
      specifies a clarifying comment on an RFC.

   4.5  Abstract

      Every RFC must have an Abstract section following the Copyright
      notice.  An Abstract will typically be 5-10 lines, but an Abstract
      of more than 20 lines is generally not acceptable.

      The Abstract section should provide a concise and comprehensive
      overview of the purpose and contents of the entire document, to
      give a technically knowledgable reader a general overview of the
      function of the document. In addition to its function in the RFC
      itself, the Abstract section text will appear in publication
      announcements and in the online index of RFCs.

      Composing a useful Abstract generally requires thought and care.
      Usually an Abstract should begin with a phrase like "This memo
      ..." or "This document ...".  A satisfactory abstract can often be
      constructed in part from material within the Introduction section,
      but a good abstract will be shorter, less detailed, and perhaps
      broader in scope than the Introduction.  Simply copying and
      pasting the first few paragraphs of the Introduction is tempting,
      but it may result in an Abstract that is both incomplete and
      redundant.  Note also that an Abstract is not a substitute for an
      Introduction; the RFC should be self-contained as if there were no
      Abstract section.

      An Abstract should be complete in itself; it should not contain
      citations unless they are completely defined within the Abstract.
      Mnemonics appearing in the Abstract should generally be expanded
      in parentheses.  There is a small set of reasonable exceptions to
      this rule; for example, readers do not need to be reminded of the
      meaning of the mnemonics "IP" or "TCP" or "MIB".  In the end this
      is a judgment call, but please err on the side of explicitness.

   4.6  Table of Contents

      A Table of Contents (TOC) section is required in RFCs longer than
      30 pages and recommended for an RFC longer than 15 pages.




RFC Editor                   Informational                     [Page 23]


Internet-Draft        Instructions to RFC Authors          23 April 2002


      A TOC must be positioned after the Abstract and before the
      Introduction section (i.e., after the "boiler plate" and before
      the body of the RFC.)

      The TOC itself should not be too long or detailed, or it loses
      value.  For example, if many successive TOC entries point to the
      same pages of the memo, the TOC probably needs to be coarser.

      No specific format is required, but the following example
      illustrates a useful format:

   1.  INTRODUCTION ...............................................    5
      1.1  The Internet Architecture ..............................    6
         1.1.1  Internet Hosts ....................................    6
         1.1.2  Architectural Assumptions .........................    7
         1.1.3  Internet Protocol Suite ...........................    8
         1.1.4  Embedded Gateway Code .............................   10
      1.2  General Considerations .................................   12
         1.2.1  Continuing Internet Evolution .....................   12
         1.2.2  Robustness Principle ..............................   12
         1.2.3  Error Logging .....................................   13

   4.7  Body of Memo

      Following the Table of Contents, if any, comes the body of the
      memo.  Depending upon the length of the TOC, a judicious page
      break can improve readability.

      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 document, e.g., whether it
      specifies a protocol, provides a discussion of some problem, is
      simply of interest to the Internet community, or provides a status
      report on some activity.

      Many RFC documents have appendices, some of which may be very
      extensive.  It is often customary in academic publications to
      place appendices at the very end, after references.  This is
      permissible in an RFC, but we recommend that an author place any
      appendices at the end of the body of the text and before the
      references.  This is appropriate because the references of an RFC
      may be normative and should therefore be clearly accessible at the
      very end of the document.

      All abbreviations that are used in the body must be expanded the
      first time they occur.  A few exceptions will be made for
      abbreviations that are so well known that expansion is
      unnecessary, e.g., TCP or IP.



RFC Editor                   Informational                     [Page 24]


Internet-Draft        Instructions to RFC Authors          23 April 2002


   4.8  References Section

      Nearly all RFCs contain citations to other documents, listed 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; in particular, see the Reference section of
      this RFC for an example.

      For a reference to an RFC that has been assigned an STD, BCP, or
      FYI subseries number, that subseries number must be included in
      the reference.

      Reference lists must indicate whether each reference is normative
      or informative.  For example, if both normative and informative
      references are included, then the reference section should be
      split into two sections, e.g.:

              s. Normative References

                   xxx
                   ...
                   xxx

             s+1. Informative References

                   xxx
                   ...
                   xxx

      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.  If these words are
      used and capitalized, RFC 2119 should be cited (as specified in
      RFC 2119) and included as a normative reference.

      Non-normative references to Internet-Drafts are allowed, but they
      must take the following restricted form: the author(s), the title,
      and the phrase "Work in Progress", for example:

           [6]   Doe, J., "The Deployment of IPv6", Work in Progress.

      The use of URLs in references in RFCs is discouraged, because URLs
      are often not stable references.  Exceptions will be made in
      certain cases where the World Wide Web is demonstrably the most
      stable reference available.

   4.9  Security Considerations Section



RFC Editor                   Informational                     [Page 25]


Internet-Draft        Instructions to RFC Authors          23 April 2002


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

   4.10  IANA Considerations Section

      Any RFC that defines a new "namespace" [9] of assigned numbers
      should include an IANA Considerations section specifying how that
      space should be administered; see Section 2.10 above and [9].

   4.11  Contributors Section

      This optional section lists those contributors who deserve
      significant credit for the document.  When a long author list is
      replaced by a single Editor in the front page header, the
      displaced authors can be properly and fully acknowledged in the
      Contributors section.

      The Contributors section may include brief statements about the
      nature of particular contributions ("Sam contributed section 3")
      and it may also include affiliations of listed contributors.  At
      the discretion of the author(s), contact addresses (see Authors'
      Address section below) may also be included in the Contributors
      section, for those contributors whose knowledge makes them useful
      future contacts for information about the RFC.

      There is no fixed position for a Contributors section or an
      Acknowledgments section within the body of the RFC.  If they
      appear, they must appear later than the Abstract section and
      earlier than the Authors' Address section.

   4.12  Acknowledgment Section

      This optional section may be used instead of, or in addition to, a
      Contributors section, when appropriate.

   4.13  Authors' Address Section

      This required section gives the name(s) and contact information
      for the author(s) listed in the first-page header.  Contact
      informatiokn must include at least one, and ideally would include
      all, of a postal address, a telephone number and/or FAX number,
      and a long-lived email address.  The purpose of this section is to
      (1) unambiguously define author/contributor identity (e.g., the
      John Smith who works for FooBar Systems) and to (2) provide
      contact information for future readers who have questions or
      comments.  Note that some professional societies offer long-lived
      email addresses for their members.



RFC Editor                   Informational                     [Page 26]


Internet-Draft        Instructions to RFC Authors          23 April 2002


   4.14  Full Copyright Statement

      Per BCP 9, RFC 2026 [2], "The following copyright notice and
      disclaimer shall be included in all ISOC standards-related
      documentation."  This is the "Full Copyright Statement", whose
      text will be found at the end of this RFC as well as in RFC 2026.

      A specific request from the IAB is required before the RFC Editor
      can include a dual copyright, or for any other variation of the
      standard ISOC copyright notice.

5.  RFC Information and Contacts

       ************************************************************
       *                                                          *
       *    RFC Editor Email:  rfc-editor@rfc-editor.org          *
       *                                                          *
       *                                                          *
       *    RFC Editor URL:  http://www.rfc-editor.org            *
       *                                                          *
       *                                                          *
       ************************************************************

   RFC publication announcements are distributed via two mailing lists:
   the "IETF-Announce" list and the "RFC-DIST" list.  The IETF-Announce
   list announces publication of both Internet Drafts and RFCs;
   instructions for subscription and unsubscription to this list are
   available on the IETF web site www.ietf.org.  The RFC-DIST list
   announces only RFC publication; subscription information is available
   on the RFC Editor web site above.

   RFC readers should be aware that the many mirrors of RFCs and RFC
   indexes that appear on other sites vary a great deal in reliability.
   Consulting the official RFC-Editor site listed above is recommended.

6. Acknowledgments

   This memo includes wording taken from a draft written by Robert W.
   Shirey of GTE/BBN Technologies, 29 December 1999, with permission.
   Shirey's deconstruction of the formatting rules was very helpful in
   writing Sections 3 and 4 of the present memo.










RFC Editor                   Informational                     [Page 27]


Internet-Draft        Instructions to RFC Authors          23 April 2002


APPENDIX A: RFC Boilerplate

   This Appendix defines standard wording required in every RFC.

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




















RFC Editor                   Informational                     [Page 28]


Internet-Draft        Instructions to RFC Authors          23 April 2002


APPENDIX B: RFC Preparation Tools

   As indicated earlier, the primary submission format for RFCs is ASCII
   text.  Authors have found various tools to be useful for preparing
   this text in the format required by RFCs and Internet-Drafts.  For
   more complete and uptodate information, see the RFC Editor Web page.

   This Appendix surveys some of the possibilities.

   nroff, groff
        The nroff program is widely available for Unix systems, while
        its freeware equivalent groff is available for an even wider
        range of platforms, including Windows.  These programs use
        directives in the text to control the formatting.  The RFC
        Editor, in particular, uses nroff for final RFC formatting.  A
        template is available as 2-nroff.template.

   XML
        An XML DTD for RFCs has been developed [7].  There is also an
        XML-to-nroff translator suitable for creating RFC text.  RFC
        Editor experience with this procedure is limited, but it has
        worked very well.

   Microsoft Word
        Microsoft Word is an important example of a WYSIWYG editor.  RFC
        3285 [14] describes in detail how to configure Word to produce
        an ASCII text file in RFC format.  A version of this document as
        a Word file (2-Word.template.rtf) can be used as a template file
        to initialize this configuration for entering and displaying
        RFCs.  There is also a DOS executable (crlf.exe) for a post-
        processor to establish RFC end-of-line conventions in the Word
        output file.

   LaTeX
        LaTeX is widely used for text preparation in many academic
        environments.  A convenient LaTex template is available as 2-
        latex.template.  Latex in general does not produce plain ASCII
        text in the RFC format, but there are tools that translate LaTex
        to nroff; see the RFC Editor web page.












RFC Editor                   Informational                     [Page 29]


Internet-Draft        Instructions to RFC Authors          23 April 2002


APPENDIX C: Checklist

Topic                                                      | Section of
                                                           | this doc.
___________________________________________________________|___________
A. Editorial/Content Issues                                |
                                                           |
    1.  Reasonably clear and correct English               |  2.3
            > Also, run spell checker                      |
                                                           |
    2.  All abbreviations (with a few exceptions) are      |  4.7
        expanded when they first appear.                   |
                                                           |
    3.  References:                                        |  2.7, 4.8
            > Complete and current                         |
            > Normative and Informative listed separately  |  2.7
            > Internet Drafts correctly referenced         |  4.8
                                                           |
    4.  All URLs are suspect: they must be stable.         |  2.8
                                                           |
    5.  Title:                                             |  2.9
            > Descriptive and not misleading.              |
            > No suspect words, e.g., Proposed, Standard,  |
                                Requirements, Policy.      |
            > Abbreviations expanded                       |
                                                           |
    6.  Author list not too long                           |  2.12
                                                           |
    7.  Category field correct                             |  4.1
                                                           |
B. Basic Formatting                                        |  3.1
                                                           |
    1.  Only printable ASCII characters                    |  3.1(1),
                                                           |    3.1(4)
    2.  No lines exceeding 72 characters                   |  3.1(2)
        [This is especially important for "as is" tables   |
         and figures, which cannot be easily reformatted by|
         the RFC Editor.]                                  |
                                                           |
    3. Maximum page size is 58 lines.  [RFC Editor may     |  3.1(3)
         re-paginate, but this limit may be an issue for   |
         large "as is" tables and figures.                 |
                                                           |
    4.  Must be ragged-right                               |  3.1(5)
                                                           |
    5.  No hyphenation at end of line                      |  3.1(6)
                                                           |
    6.  Two blanks after periods ending sentences          |  3.1(7)



RFC Editor                   Informational                     [Page 30]


Internet-Draft        Instructions to RFC Authors          23 April 2002


                                                           |
    7.  No footnotes (end notes OK)                        |  3.1(8)
                                                           |
    8.  Line spacing OK                                    |  3.1(9)
                                                           |
    9.  Pages numbered                                     |  3.1(10)
                                                           |
   10.  Running headers and footers OK                     |  3.3
                                                           |
   11.  Formatted for easy reading; consistent spacing and |
        indentation                                        |  3.1(12)
                                                           |
   12.  "Big-Endian" data definitions                      |  3.4
                                                           |
C. Required Sections                                       |  4
                                                           |
    1.  Status of Memo                                     |  4.2
            > Choose text appropriate to Category          |  App. B
                                                           |
    2.  Copyright Notice                                   |  4.3
                                                           |
    3.  Abstract                                           |  4.5
            > Clarity and content OK                       |
            > Reasonable length                            |
            > All abbreviations expanded                   |
            > No references                                |
            > Unnumbered section                           |
                                                           |
    4.  Security Considerations                            |  4.9
                                                           |
    5.  Authors' Addresses                                 |  4.13
                                                           |
B. Optional Sections                                       |  4
                                                           |
    1.  IESG Note, if requested.                           |  4.4
                                                           |
    2.  Table of Contents                                  |  4.6
            > Must be present in large document            |
                                                           |
    3.  IANA Considerations, if needed                     |  4.10

    4.  Contributors and/or Acknowledgments                | 4.11, 4.12









RFC Editor                   Informational                     [Page 31]


Internet-Draft        Instructions to RFC Authors          23 April 2002


APPENDIX D: Changes from RFC 2223

   Section 1: Introduction

      This section was completely rewritten, using material from several
      sections of RFC 2223 and bringing the discussion into conformance
      with RFC 2026.

   Section 2: RFC Editorial and Publication Policies

      This section combines material from several sections of RFC 2223.
      New material is included about the RFC Editor errata page,
      normative references, URLs, titles, RFC number pre-assignment,
      author lists, and IANA Considerations.

      There are four changes of procedure: (1) publication of an RFC in
      both ASCII and Postscript versions now requires that both be
      published simultaneously, (2) all listed authors must give
      approval during the "Authors' 48 Hour" process, (3) long author
      lists are generally prohibited, and (4) a Contributors section is
      defined as an alternative to long author lists.

   Section 3: General Format Rules

      This section is expanded with much additional explanatory
      material.  For example:

           (1)  The requirement for printable ASCII characters is
                stated, and the use of CR, LF, and FF is clarified.

           (2)  The requirement for page numbers in specified.

           (3)  The requirement for running headers and footers is
                specified.

   Section 4: Required Sections in an RFC

      This section is reorganized to cover all the required sections of
      an RFC in order.  It adds the current conventions for formatting
      multiple author names and organizations.

      This section describes four major changes in RFC formatting.

           (1)  The style and contents of the Abstract section are more
                completely specified, in order to make RFC abstracts
                useful for searching and indexing.

           (2)  A Table of Contents section is required or recommended



RFC Editor                   Informational                     [Page 32]


Internet-Draft        Instructions to RFC Authors          23 April 2002


                in all but very short RFCs.

           (3)  Separate lists are now required for normative references
                and informative references.

           (4)  A new optional section, Contributors, is defined.

   Appendixes

      Former Appendix A, which contained the source for the fix.pl
      post-processor Perl script and an nroff RFC template, has been
      removed.  These files are available at the RFC Editor web site.

      Appendix B, RFC Preparation Tools, and Appendix C, Checklist, are
      new.

Normative References

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [10] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names", RFC
        2606, June 1999.

   [11] Cerf, V., "ASCII Format for Network Interchange", RFC 20,
        October 1969.

Informative References

   [1]  RFC Editor et al., "30 Years of RFCs", RFC 2555, 7 April 1999.

   [4]  Malkin, G. and J. Reynolds, "F.Y.I. on F.Y.I Introduction to the
        F.Y.I. Notes", FYI 1, RFC 1150, March 1990.

   [5]  Postel, J., Li, T. and Y. Rekhter, "Best Current Practices", BCP
        1, RFC 1818, August 1995.

   [6]  Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
        March 1992.

   [7]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
        1999.

   [8]  Cohen, D., "On Holy Wars and a Plea for Peace", Internet
        Experimental Note (IEN) 137, 1 April 1980.  A longer version is



RFC Editor                   Informational                     [Page 33]


Internet-Draft        Instructions to RFC Authors          23 April 2002


        published in IEEE Computer Magazine, pp 48-54, October 1981.

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [12] IETF, "Guidelines to Authors of Internet Drafts".  Available as
        1id-guidelines.txt at http://www.ietf.org.

   [13] Rescorla, E., Korver, B., and Internet Architecture Board,
        "Guidelines for Writing RFC Text on Security Considerations",
        Work in Progress, August 2002.

   [14] Garhns, M. and T. Hain, "Using Microsoft Word to create Internet
        Drafts and RFCs", RFC 3285, May 2002.
Security Considerations

   This RFC describes the Security Considerations sections of an RFC.

Authors' Addresses

   Joyce K. Reynolds
   RFC Editor
   4676 Admiralty Way
   Marina del Rey, CA  90292

   EMail: rfc-editor@rfc-editor.org


   Robert Braden
   RFC Editor
   4676 Admiralty Way
   Marina del Rey, CA  90292

   EMail: rfc-editor@rfc-editor.org

















RFC Editor                   Informational                     [Page 34]


Internet-Draft        Instructions to RFC Authors          23 April 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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 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.

Acknowledgement:

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















RFC Editor                   Informational                     [Page 35]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/