home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2223 < prev    next >
Text File  |  1997-10-22  |  38KB  |  1,124 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Postel
  8. Request for Comments: 2223                                   J. Reynolds
  9. Obsoletes: 1543, 1111, 825                                           ISI
  10. Category: Informational                                     October 1997
  11.  
  12.  
  13.                       Instructions to RFC Authors
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Copyright Notice
  22.  
  23.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  24.  
  25. Table of Contents
  26.  
  27.    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  28.    2.   Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
  29.    3.   Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
  30.    3a.   ASCII Format Rules  . . . . . . . . . . . . . . . . . . . . 5
  31.    3b.   PostScript Format Rules . . . . . . . . . . . . . . . . . . 6
  32.    4.   Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  33.    4a.   First Page Heading  . . . . . . . . . . . . . . . . . . . . 7
  34.    4b.   Running Header  . . . . . . . . . . . . . . . . . . . . . . 8
  35.    4c.   Running Footer  . . . . . . . . . . . . . . . . . . . . . . 8
  36.    5.   Status Section . . . . . . . . . . . . . . . . . . . . . . . 8
  37.    6.   Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 9
  38.    7.   Introduction Section . . . . . . . . . . . . . . . . . . . . 9
  39.    8.   References Section . . . . . . . . . . . . . . . . . . . .  11
  40.    9.   Security Considerations Section  . . . . . . . . . . . . .  11
  41.    10.  Author's Address Section . . . . . . . . . . . . . . . . .  11
  42.    11.  Copyright Section  . . . . . . . . . . . . . . . . . . . .  11
  43.    12.  Relation to other RFCs . . . . . . . . . . . . . . . . . .  12
  44.    13.  Protocol Standards Process . . . . . . . . . . . . . . . .  13
  45.    14.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  46.    15.  Distribution Lists . . . . . . . . . . . . . . . . . . . .  14
  47.    16.  RFC Index  . . . . . . . . . . . . . . . . . . . . . . . .  14
  48.    17.  Security Considerations  . . . . . . . . . . . . . . . . .  14
  49.    18.  References . . . . . . . . . . . . . . . . . . . . . . . .  14
  50.    19.  Authors' Addresses . . . . . . . . . . . . . . . . . . . .  15
  51.    20.  Appendix - RFC "nroff macros"  . . . . . . . . . . . . . .  16
  52.    21.  Full Copyright Statement . . . . . . . . . . . . . . . . .  20
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Postel & Reynolds            Informational                      [Page 1]
  59.  
  60. RFC 2223              Instructions to RFC Authors           October 1997
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    This Request for Comments (RFC) provides information about the
  66.    preparation of RFCs, and certain policies relating to the publication
  67.    of RFCs.
  68.  
  69.    The RFC series of notes covers a broad range of interests.  The core
  70.    topics are the Internet and the TCP/IP protocol suite.  However, any
  71.    topic related to computer communication may be acceptable at the
  72.    discretion of the RFC Editor.
  73.  
  74.    Memos proposed to be RFCs may be submitted by anyone.  One large
  75.    source of memos that become RFCs is the Internet Engineering Task
  76.    Force (IETF).  The IETF working groups (WGs) evolve their working
  77.    memos (known as Internet Drafts or I-Ds) until they feel they are
  78.    ready for publication, then the memos are reviewed by the Internet
  79.    Engineering Steering Group (IESG), and if approved sent by the IESG
  80.    to the RFC Editor.
  81.  
  82.    Most of the memos submitted to the RFC Editor from independent
  83.    sources will be reviewed by the IESG for possible relationship to
  84.    work in progress in the IETF Working Groups.
  85.  
  86.    RFCs are distributed online by being stored as public access files,
  87.    and a short message is sent to the distribution list indicating the
  88.    availability of the memo.
  89.  
  90.    The online files are copied by the interested people and printed or
  91.    displayed at their site on their equipment.  This means that the
  92.    format of the online files must meet the constraints of a wide
  93.    variety of printing and display equipment.  (RFCs may also be
  94.    returned via e-mail in response to an e-mail query, or RFCs may be
  95.    found using information and database searching tools such as Gopher,
  96.    Wais, or the World Wide Web (WWW).
  97.  
  98.    RFCs have been traditionally published and continue to be published
  99.    in ASCII text.
  100.  
  101.    While the primary RFCs is always an ASCII text file, secondary or
  102.    alternative versions of RFC may be provided in PostScript.  This
  103.    decision is motivated by the desire to include diagrams, drawings,
  104.    and such in RFCs.  PostScript documents (on paper only, so far) are
  105.    visually more appealing and have better readability.
  106.  
  107.    PostScript was chosen for the fancy form of RFC publication over
  108.    other possible systems (e.g., impress, interpress, oda) because of
  109.    the perceived wide spread availability of PostScript capable
  110.    printers.
  111.  
  112.  
  113.  
  114. Postel & Reynolds            Informational                      [Page 2]
  115.  
  116. RFC 2223              Instructions to RFC Authors           October 1997
  117.  
  118.  
  119.    However, many RFC users read the documents online and use various
  120.    text oriented tools (e.g., emacs, grep) to search them.  Often, brief
  121.    excerpts from RFCs are included in e-mail.  These practices are not
  122.    yet practical with PostScript files.
  123.  
  124.    PostScript producing systems are less standard than is desirable and
  125.    that several of the document production systems that claim to produce
  126.    PostScript actually produce nonstandard results.
  127.  
  128.    In the future, it may be necessary to identify a set of document
  129.    production systems authorized for use in production of PostScript
  130.    RFCs, based on the reasonableness of the output files they generate.
  131.  
  132. 2.  Editorial Policy
  133.  
  134.    Documents proposed to be RFCs are reviewed by the RFC Editor and
  135.    possibly by other reviewers he selects.
  136.  
  137.    The result of the review may be to suggest to the author some
  138.    improvements to the document before publication.
  139.  
  140.    Occasionally, it may be apparent that the topic of a proposed RFC is
  141.    also the subject of an IETF Working Group, and that the author could
  142.    coordinate with the working group to the advantage of both.  The
  143.    usual result of this is that a revised memo is produced as a working
  144.    group Internet Draft and eventually emerges from the IETF process as
  145.    a recommendation from the IESG to the RFC Editor.
  146.  
  147.    In some cases it may be determined that the submitted document is not
  148.    appropriate material to be published as an RFC.
  149.  
  150.    In some cases it may be necessary to include in the document a
  151.    statement based on the reviews about the ideas in the document.  This
  152.    may be done in the case that the document suggests relevant but
  153.    inappropriate or unsafe ideas, and other situations.
  154.  
  155.    The RFC Editor may make minor changes to the document, especially in
  156.    the areas of style and format, but on some occasions also to the
  157.    text.  Sometimes the RFC Editor will undertake to make more
  158.    significant changes, especially when the format rules (see below) are
  159.    not followed.  However, more often the memo will be returned to the
  160.    author for the additional work.
  161.  
  162.    Documents intended to become RFCs specifying standards track
  163.    protocols must be approved by the IESG before being sent to the RFC
  164.    Editor.  The established procedure is that when the IESG completes
  165.    work on a document that is to become a standards track RFC the
  166.    communication will be from the Secretary of the IESG to the RFC
  167.  
  168.  
  169.  
  170. Postel & Reynolds            Informational                      [Page 3]
  171.  
  172. RFC 2223              Instructions to RFC Authors           October 1997
  173.  
  174.  
  175.    Editor.  Generally, the documents in question are Internet Drafts.
  176.    The communication usually cites the exact Internet Draft in question
  177.    (by file name).  The RFC Editor must assume that only that file is to
  178.    be processed to become the RFC.  If the authors have small
  179.    corrections to the text, they should be sent to the RFC Editor
  180.    separately (or as a "diff"), authors should not send a new version of
  181.    the document.
  182.  
  183.    In some cases, authors prepare alternate secondary versions of RFCs
  184.    in fancy format using PostScript.  Since the ASCII text version of
  185.    the RFC is the primary version, the PostScript version must match the
  186.    text version.  The RFC Editor must decide if the PostScript version
  187.    is "the same as" the ASCII version before the PostScript version can
  188.    be published.
  189.  
  190.    The effect of this is that the RFC Editor first processes the ASCII
  191.    version of the memo through to publication as an RFC.  If the author
  192.    wishes to submit a PostScript version at that point that matches the
  193.    ASCII version (and the RFC Editor agrees that it does), then the
  194.    PostScript version will be installed in the RFC repositories and
  195.    announced to the community.
  196.  
  197.    Due to various time pressures on the RFC Editorial staff, the time
  198.    elapsed between submission and publication can vary greatly.  It is
  199.    always acceptable to query (ping) the RFC Editor about the status of
  200.    an RFC during this time (but not more than once a week).  The two
  201.    weeks preceding an IETF meeting are generally very busy, so RFCs
  202.    submitted shortly before an IETF meeting are most likely to be
  203.    published after the meeting.
  204.  
  205. 3.  Format Rules
  206.  
  207.    To meet the distribution constraints, the following rules are
  208.    established for the two allowed formats for RFCs:  ASCII and
  209.    PostScript.
  210.  
  211.    The RFC Editor attempts to ensure a consistent RFC style.  To do this
  212.    the RFC Editor may choose to reformat the RFC submitted.  It is much
  213.    easier to do this if the submission matches the style of the most
  214.    recent RFCs.  Please do look at some recent RFCs and prepare yours in
  215.    the same style.
  216.  
  217.    You must submit an editable online document to the RFC Editor.  The
  218.    RFC Editor may require or make minor changes in format or style and
  219.    will insert the actual RFC number.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Postel & Reynolds            Informational                      [Page 4]
  227.  
  228. RFC 2223              Instructions to RFC Authors           October 1997
  229.  
  230.  
  231.    Most of the RFCs are processed by the RFC Editor with the unix
  232.    "nroff" program using a very simple set of the formatting commands
  233.    (or "requests") from the "ms" macro package (see the Appendix).  If a
  234.    memo submitted to be an RFC has been prepared by the author using
  235.    nroff, it is very helpful to let the RFC Editor know that when it is
  236.    submitted.
  237.  
  238.    3a.  ASCII Format Rules
  239.  
  240.       The character codes are ASCII.
  241.  
  242.       Each page must be limited to 58 lines followed by a form feed on a
  243.       line by itself.
  244.  
  245.       Each line must be limited to 72 characters followed by carriage
  246.       return and line feed.
  247.  
  248.       No overstriking (or underlining) is allowed.
  249.  
  250.       These "height" and "width" constraints include any headers,
  251.       footers, page numbers, or left side indenting.
  252.  
  253.       Do not fill the text with extra spaces to provide a straight right
  254.       margin.
  255.  
  256.       Do not do hyphenation of words at the right margin.
  257.  
  258.       Do not use footnotes.  If such notes are necessary, put them at
  259.       the end of a section, or at the end of the document.
  260.  
  261.       Use single spaced text within a paragraph, and one blank line
  262.       between paragraphs.
  263.  
  264.       Note that the number of pages in a document and the page numbers
  265.       on which various sections fall will likely change with
  266.       reformatting.  Thus cross references in the text by section number
  267.       usually are easier to keep consistent than cross references by
  268.       page number.
  269.  
  270.       RFCs in ASCII Format may be submitted to the RFC Editor in e-mail
  271.       messages (or as online files) in either the finished publication
  272.       format or in nroff.  If you plan to submit a document in nroff
  273.       please consult the RFC Editor first.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Postel & Reynolds            Informational                      [Page 5]
  283.  
  284. RFC 2223              Instructions to RFC Authors           October 1997
  285.  
  286.  
  287.    3b.  PostScript Format Rules
  288.  
  289.       Standard page size is 8 1/2 by 11 inches.
  290.  
  291.       Margin of 1 inch on all sides (top, bottom, left, and right).
  292.  
  293.       Main text should have a point size of no less than 10 points with
  294.       a line spacing of 12 points.
  295.  
  296.       Footnotes and graph notations no smaller than 8 points with a line
  297.       spacing of 9.6 points.
  298.  
  299.       Three fonts are acceptable: Helvetica, Times Roman, and Courier.
  300.       Plus their bold-face and italic versions.  These are the three
  301.       standard fonts on most PostScript printers.
  302.  
  303.       Prepare diagrams and images based on lowest common denominator
  304.       PostScript.  Consider common PostScript printer functionality and
  305.       memory requirements.
  306.  
  307.       The following PostScript commands should not be used:
  308.       initgraphics, erasepage, copypage, grestoreall, initmatrix,
  309.       initclip, banddevice, framedevice, nulldevice and renderbands.
  310.  
  311.       Note that the number of pages in a document and the page numbers
  312.       on which various sections fall will likely differ in the ASCII and
  313.       the PostScript versions.  Thus cross references in the text by
  314.       section number usually are easier to keep consistent than cross
  315.       references by page number.
  316.  
  317.       These PostScript rules are likely to changed and expanded as
  318.       experience is gained.
  319.  
  320.       RFCs in PostScript Format may be submitted to the RFC Editor in
  321.       e-mail messages (or as online files).  If you plan to submit a
  322.       document in PostScript please consult the RFC Editor first.
  323.  
  324.       Note that since the ASCII text version of the RFC is the primary
  325.       version, the PostScript version must match the text version.  The
  326.       RFC Editor must decide if the PostScript version is "the same as"
  327.       the ASCII version before the PostScript version can be published.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Postel & Reynolds            Informational                      [Page 6]
  339.  
  340. RFC 2223              Instructions to RFC Authors           October 1997
  341.  
  342.  
  343. 4.  Headers and Footers
  344.  
  345.    There is the first page heading, the running headers, and the running
  346.    footers.
  347.  
  348.    4a.  First Page
  349.  
  350.       Please see the front page of this memo for an example of the front
  351.       page heading.  On the first page there is no running header.  The
  352.       top of the first page has the following items:
  353.  
  354.       Network Working Group
  355.  
  356.          The traditional heading for the group that founded the RFC
  357.          series.  This appears on the first line on the left hand side
  358.          of the heading.
  359.  
  360.       Request for Comments: nnnn
  361.  
  362.          Identifies this as a request for comments and specifies the
  363.          number.  Indicated on the second line on the left side.  The
  364.          actual number is filled in at the last moment before
  365.          publication by the RFC Editor.
  366.  
  367.       Author
  368.  
  369.          The author's name (first initial and last name only) indicated
  370.          on the first line on the right side of the heading.
  371.  
  372.       Organization
  373.  
  374.          The author's organization, indicated on the second line on the
  375.          right side.
  376.  
  377.       Date
  378.  
  379.          This is the Month and Year of the RFC Publication. Indicated on
  380.          the third line on the right side.
  381.  
  382.       Updates or Obsoletes
  383.  
  384.          If this RFC Updates or Obsoletes another RFC, this is indicated
  385.          as third line on the left side of the heading.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Postel & Reynolds            Informational                      [Page 7]
  395.  
  396. RFC 2223              Instructions to RFC Authors           October 1997
  397.  
  398.  
  399.       Category
  400.  
  401.          The category of this RFC, one of: Standards Track, Best Current
  402.          Practice, Informational, or Experimental.  This is indicated on
  403.          the third (if there is no Updates or Obsoletes indication) or
  404.          fourth line of the left side.
  405.  
  406.       Other Numbers
  407.  
  408.          Other numbers in the RFC series of notes include the subseries
  409.          of FYI (For Your Information) [4], BCP (Best Current Practice)
  410.          [5], and STD (Standard) [6].  These are placed on the left
  411.          side.
  412.  
  413.       Title
  414.  
  415.          The title appears, centered, below the rest of the heading.
  416.          Periods or "dots" in the titles are not allowed.
  417.  
  418.       If there are multiple authors and if the multiple authors are from
  419.       multiple organizations the right side heading may have additional
  420.       lines to accommodate them and to associate the authors with the
  421.       organizations properly.
  422.  
  423.    4b.  Running Headers
  424.  
  425.       The running header in one line (on page 2 and all subsequent
  426.       pages) has the RFC number on the left (RFC NNNN), the (possibly
  427.       nshortened form) title centered, and the date (Month Year) on the
  428.       right.
  429.  
  430.    4c.  Running Footers
  431.  
  432.       The running footer in one line (on all pages) has the author's
  433.       last name on the left, category centered, and the page number on
  434.       the right ([Page N]).
  435.  
  436. 5.  Status Section
  437.  
  438.    Each RFC must include on its first page the "Status of this Memo"
  439.    section which contains two elements: (1) a paragraph describing the
  440.    type of the RFC, and (2) the distribution statement.
  441.  
  442.    The content of this section will be one of the four following
  443.    statements.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Postel & Reynolds            Informational                      [Page 8]
  451.  
  452. RFC 2223              Instructions to RFC Authors           October 1997
  453.  
  454.  
  455.    Standards Track
  456.  
  457.       "This document specifies an Internet standards track protocol for
  458.       the Internet community, and requests discussion and suggestions
  459.       for improvements.  Please refer to the current edition of the
  460.       "Internet Official Protocol Standards" (STD 1) for the
  461.       standardization state and status of this protocol.  Distribution
  462.       of this memo is unlimited."
  463.  
  464.    Best Current Practice
  465.  
  466.       "This document specifies an Internet Best Current Practices for
  467.       the Internet Community, and requests discussion and suggestions
  468.       for improvements.  Distribution of this memo is unlimited."
  469.  
  470.    Experimental
  471.  
  472.       "This memo defines an Experimental Protocol for the Internet
  473.       community.  This memo does not specify an Internet standard of any
  474.       kind.  Discussion and suggestions for improvement are requested.
  475.       Distribution of this memo is unlimited."
  476.  
  477.    Informational
  478.  
  479.       "This memo provides information for the Internet community.  This
  480.       memo does not specify an Internet standard of any kind.
  481.       Distribution of this memo is unlimited."
  482.  
  483. 6.  Copyright Notice
  484.  
  485.    Immediately following the Status section the statement, "Copyright
  486.    (C) The Internet Society (date).  All Rights Reserved." is placed.
  487.    Also, see Section 11 for the full statement that must appear at the
  488.    end of the document.
  489.  
  490. 7.  Introduction Section
  491.  
  492.    Each RFC should have an Introduction section that (among other
  493.    things) explains the motivation for the RFC and (if appropriate)
  494.    describes the applicability of the protocol described.
  495.  
  496.       Normally, this will be the "abstract" section from the Internet
  497.       Draft.  If the RFC is not based on an I-D, other possibilities
  498.       are:
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Postel & Reynolds            Informational                      [Page 9]
  507.  
  508. RFC 2223              Instructions to RFC Authors           October 1997
  509.  
  510.  
  511.          Protocol
  512.  
  513.             This protocol is intended to provide the bla-bla service,
  514.             and be used between clients and servers on host computers.
  515.             Typically the clients are on workstation hosts and the
  516.             servers on mainframe hosts.
  517.  
  518.             or
  519.  
  520.             This protocol is intended to provide the bla-bla service,
  521.             and be used between special purpose units such as terminal
  522.             servers or routers and a monitoring host.
  523.  
  524.          Discussion
  525.  
  526.             The purpose of this RFC is to focus discussion on particular
  527.             problems in the Internet and possible methods of solution.
  528.             No proposed solutions in this document are intended as
  529.             standards for the Internet.  Rather, it is hoped that a
  530.             general consensus will emerge as to the appropriate solution
  531.             to such problems, leading eventually to the adoption of
  532.             standards.
  533.  
  534.          Interest
  535.  
  536.             This RFC is being distributed to members of the Internet
  537.             community in order to solicit their reactions to the
  538.             proposals contained in it.  While the issues discussed may
  539.             not be directly relevant to the research problems of the
  540.             Internet, they may be interesting to a number of researchers
  541.             and implementers.
  542.  
  543.          Status Report
  544.  
  545.             In response to the need for maintenance of current
  546.             information about the status and progress of various
  547.             projects in the Internet community, this RFC is issued for
  548.             the benefit of community members.  The information contained
  549.             in this document is accurate as of the date of publication,
  550.             but is subject to change.  Subsequent RFCs will reflect such
  551.             changes.
  552.  
  553.       These paragraphs need not be followed word for word, but the
  554.       general intent of the RFC must be made clear.
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Postel & Reynolds            Informational                     [Page 10]
  563.  
  564. RFC 2223              Instructions to RFC Authors           October 1997
  565.  
  566.  
  567. 8.  References Section
  568.  
  569.    Nearly all RFCs contain citations to other documents, and these are
  570.    listed in a References section near the end of the RFC.  There are
  571.    many styles for references, and the RFCs have one of their own.
  572.    Please follow the reference style used in recent RFCs.  See the
  573.    reference section of this RFC for an example.  Please note that for
  574.    protocols that have been assigned STD numbers, the STD number must be
  575.    included in the reference.
  576.  
  577.    In many standards track documents several words are used to signify
  578.    the requirements in the specification.  These words are often
  579.    capitalized.  BCP 14, RFC 2119 [3], defines these words as they
  580.    should be interpreted in IETF documents.
  581.  
  582. 9.  Security Considerations Section
  583.  
  584.    All RFCs must contain a section near the end of the document that
  585.    discusses the security considerations of the protocol or procedures
  586.    that are the main topic of the RFC.
  587.  
  588. 10.  Author's Address Section
  589.  
  590.    Each RFC must have at the very end a section giving the author's
  591.    address, including the name and postal address, the telephone number,
  592.    (optional: a FAX number) and the Internet email address.
  593.  
  594. 11.  Copyright Section
  595.  
  596.    Per BCP 9, RFC 2026 [2], "The following copyright notice and
  597.    disclaimer shall be included in all ISOC standards-related
  598.    documentation."  The following statement should be placed on the last
  599.    page of the RFC, as the "Full Copyright Statement".
  600.  
  601.       "Copyright (C) The Internet Society (date).  All Rights Reserved.
  602.  
  603.       This document and translations of it may be copied and furnished
  604.       to others, and derivative works that comment on or otherwise
  605.       explain it or assist in its implmentation may be prepared, copied,
  606.       published and distributed, in whole or in part, without
  607.       restriction of any kind, provided that the above copyright notice
  608.       and this paragraph are included on all such copies and derivative
  609.       works.  However, this document itself may not be modified in any
  610.       way, such as by removing the copyright notice or references to the
  611.       Internet Society or other Internet organizations, except as needed
  612.       for the purpose of developing Internet standards in which case the
  613.       procedures for copyrights defined in the Internet Standards
  614.       process must be followed, or as required to translate it into
  615.  
  616.  
  617.  
  618. Postel & Reynolds            Informational                     [Page 11]
  619.  
  620. RFC 2223              Instructions to RFC Authors           October 1997
  621.  
  622.  
  623.       languages other than English.
  624.  
  625.       The limited permissions granted above are perpetual and will not
  626.       be revoked by the Internet Society or its successors or assigns.
  627.  
  628.       This document and the information contained herein is provided on
  629.       an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
  630.       ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
  631.       IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  632.       THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  633.       WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  634.  
  635. 12.  Relation to other RFCs
  636.  
  637.    Sometimes an RFC adds information on a topic discussed in a previous
  638.    RFC or completely replaces an earlier RFC.  There are two terms used
  639.    for these cases respectively, Updates and Obsoletes.  A document that
  640.    obsoletes an earlier document can stand on its own.  A document that
  641.    merely updates an earlier document cannot stand on its own; it is
  642.    something that must be added to or inserted into the previously
  643.    existing document, and has limited usefulness independently.  The
  644.    terms Supercedes and Replaces are no longer used.
  645.  
  646.    Updates
  647.  
  648.       To be used as a reference from a new item that cannot be used
  649.       alone (i.e., one that supplements a previous document), to refer
  650.       to the previous document.  The newer publication is a part that
  651.       will supplement or be added on to the existing document; e.g., an
  652.       addendum, or separate, extra information that is to be added to
  653.       the original document.
  654.  
  655.    Obsoletes
  656.  
  657.       To be used to refer to an earlier document that is replaced by
  658.       this document.  This document contains either revised information,
  659.       or else all of the same information plus some new information,
  660.       however extensive or brief that new information is; i.e., this
  661.       document can be used alone, without reference to the older
  662.       document.
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Postel & Reynolds            Informational                     [Page 12]
  675.  
  676. RFC 2223              Instructions to RFC Authors           October 1997
  677.  
  678.  
  679.       For example:
  680.  
  681.          On the Assigned Numbers RFCs the term Obsoletes should be used
  682.          since the new document actually incorporate new information
  683.          (however brief) into the text of existing information and is
  684.          more up-to-date than the older document, and hence, replaces it
  685.          and makes it Obsoletes.
  686.  
  687.    In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
  688.    the following may be used with early documents to point to later
  689.    documents.
  690.  
  691.    Obsoleted-by
  692.  
  693.       To be used to refer to the newer document(s) that replaces the
  694.       older document.
  695.  
  696.    Updated-by
  697.  
  698.       To be used to refer to the newer section(s) which are to be added
  699.       to the existing, still used, document.
  700.  
  701. 13.  Protocol Standards Process
  702.  
  703.    See the current "Internet Official Protocol Standards" (STD 1) memo
  704.    for the definitive statement on protocol standards and their
  705.    publication [1].
  706.  
  707.    The established procedure is that when the IESG completes work on a
  708.    document that is to become a standards track RFC the communication
  709.    will be from the Secretary of the IESG to the RFC Editor.  Generally,
  710.    the documents in question are Internet Drafts.  The communication
  711.    usually cites the exact Internet Draft (by file name) in question.
  712.    The RFC Editor must assume that only that file is to be processed to
  713.    become the RFC.  If the authors have small corrections to the text,
  714.    they should be sent to the RFC Editor separately (or as a "diff"), do
  715.    not send a new version of the document.
  716.  
  717. 14.  Contact
  718.  
  719.    To contact the RFC Editor send an email message to:
  720.  
  721.          "rfc-editor@isi.edu".
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Postel & Reynolds            Informational                     [Page 13]
  731.  
  732. RFC 2223              Instructions to RFC Authors           October 1997
  733.  
  734.  
  735. 15.  Distribution Lists
  736.  
  737.    The RFC announcements are distributed via two mailing lists: the
  738.    "IETF-Announce" list, and the "RFC-DIST" list.  You don't want to be
  739.    on both lists.
  740.  
  741.    To join (or quit) the IETF-Announce list send a message to ietf-
  742.    request@ietf.org.
  743.  
  744.    To join (or quit) the RFC-DIST list send a message to rfc-dist-
  745.    request@isi.edu.
  746.  
  747. 16.  RFC Index
  748.  
  749.    Several organizations maintain RFC Index files, generally using the
  750.    file name "rfc-index.txt".  The contents of such a file copied from
  751.    one site may not be identical to that copied from another site.
  752.  
  753. 17.  Security Considerations
  754.  
  755.    This RFC raises no security issues (however, see Section 9).
  756.  
  757. 18.  References
  758.  
  759.    [1]  Postel, J., Editor, "Internet Official Protocol Standards", STD
  760.         1, RFC 2200, June 1997.
  761.  
  762.    [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
  763.         9, RFC 2026, October 1996.
  764.  
  765.    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
  766.         Levels", BCP 14, RFC 2119, March 1997.
  767.  
  768.    [4]  Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to
  769.         the F.Y.I. Notes", FYI 1, RFC 1150, March 1990.
  770.  
  771.    [5]  Postel, J., Li, T., and Y. Rekhter, "Best Current Practices",
  772.         BCP 1, RFC 1818, August 1995.
  773.  
  774.    [6]  Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
  775.         March 1992.
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Postel & Reynolds            Informational                     [Page 14]
  787.  
  788. RFC 2223              Instructions to RFC Authors           October 1997
  789.  
  790.  
  791. 19.  Authors' Addresses
  792.  
  793.    Jon Postel
  794.    USC/Information Sciences Institute
  795.    4676 Admiralty Way
  796.    Marina del Rey, CA  90292
  797.  
  798.    Phone: +1 310-822-1511
  799.    Fax:   +1 310-823-6714
  800.    EMail: Postel@ISI.EDU
  801.  
  802.  
  803.    Joyce K. Reynolds
  804.    USC/Information Sciences Institute
  805.    4676 Admiralty Way
  806.    Marina del Rey, CA  90292
  807.  
  808.    Phone: +1 310-822-1511
  809.    Fax:   +1 310-823-6714
  810.    EMail: jkrey@isi.edu
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Postel & Reynolds            Informational                     [Page 15]
  843.  
  844. RFC 2223              Instructions to RFC Authors           October 1997
  845.  
  846.  
  847. 20.  Appendix - RFC "nroff macros"
  848.  
  849.    Generally, we use the very simplest nroff features.  We use the "ms"
  850.    macros.  So, "nroff -ms input-file > output-file".  However, we could
  851.    not get nroff to do the right thing about putting a form feed after
  852.    the last visible line on a page and no extra line feeds before the
  853.    first visible line of the next page.  We want:
  854.  
  855.         last visible line on page i
  856.         ^L
  857.         first visible line on page i+1
  858.  
  859.    So, we invented a hack to fix this.  We use a perl script called
  860.    "fix.pl".  So the command to process the file becomes:
  861.  
  862.         nroff -ms input-file | fix.pl > output-file
  863.  
  864.    The actual perl script is:
  865.  
  866.  
  867. #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  868. #! /local/bin/perl
  869.  
  870. # fix.pl  17-Nov-93  Craig Milo Rogers at USC/ISI
  871. #
  872. #       The style guide for RFCs calls for pages to be delimited by the
  873. # sequence <last-non-blank-line><formfeed-line><first-non-blank-line>.
  874. # Unfortunately, NROFF is reluctant to produce output that conforms to
  875. # this convention.  This script fixes RFC-style documents by searching
  876. # for the token "FORMFEED[Page", replacing "FORMFEED" with spaces,
  877. # appending a formfeed line, and deleting white space up to the next
  878. # non-white space character.
  879. #
  880. #       There is one difference between this script's output and that of
  881. # the "fix.sh" and "pg" programs it replaces:  this script includes a
  882. # newline after the formfeed after the last page in a file, whereas the
  883. # earlier programs left a bare formfeed as the last character in the
  884. # file.  To obtain bare formfeeds, uncomment the second substitution
  885. # command below.  To strip the final formfeed, uncomment the third
  886. # substitution command below.
  887. #
  888. #       This script is intended to run as a filter, as in:
  889. #
  890. # nroff -ms input-file | fix.pl > output-file
  891. #
  892. #       When porting this script, please observe the following points:
  893. #
  894. # 1)    ISI keeps perl in "/local/bin/perl";  your system may keep it
  895.  
  896.  
  897.  
  898. Postel & Reynolds            Informational                     [Page 16]
  899.  
  900. RFC 2223              Instructions to RFC Authors           October 1997
  901.  
  902.  
  903. #       elsewhere.
  904. # 2)    On systems with a CRLF end-of-line convention, the "\n"s below
  905. #       may have to be replaced with "\r\n"s.
  906.  
  907. $* = 1;                                 # Enable multiline patterns.
  908. undef $/;                               # Read whole files in a single
  909.                                         # gulp.
  910.  
  911. while (<>) {                            # Read the entire input file.
  912.     s/FORMFEED(\[Page\s+\d+\])\s+/        \1\n\f\n/g;
  913.                                         # Rewrite the end-of-pages.
  914. #    s/\f\n$/\f/;                       # Want bare formfeed at end?
  915. #    s/\f\n$//;                         # Want no formfeed at end?
  916.     print;                              # Print the resultant file.
  917. }
  918. #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.    This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc-
  926.    editor/fix.pl
  927.  
  928.    Now as to the nroff features we actually use, following is a sample
  929.    memo, prepared in RFC style.
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Postel & Reynolds            Informational                     [Page 17]
  955.  
  956. RFC 2223              Instructions to RFC Authors           October 1997
  957.  
  958.  
  959. .pl 10.0i
  960. .po 0
  961. .ll 7.2i
  962. .lt 7.2i
  963. .nr LL 7.2i
  964. .nr LT 7.2i
  965. .ds LF Waitzman
  966. .ds RF PUTFFHERE[Page %]
  967. .ds CF
  968. .ds LH RFC 1149
  969. .ds RH 1 April 1990
  970. .ds CH IP Datagrams on Avian Carriers
  971. .hy 0
  972. .ad l
  973. .in 0
  974. Network Working Group                                        D. Waitzman
  975. Request for Comments: 1149                                       BBN STC
  976.                                                             1 April 1990
  977.  
  978.  
  979. .ce
  980. A Standard for the Transmission of IP Datagrams on Avian Carriers
  981.  
  982. .ti 0
  983. Status of this Memo
  984.  
  985. .fi
  986. .in 3
  987. This memo describes an experimental method for the encapsulation of IP
  988. datagrams in avian carriers.  This specification is primarily useful
  989. in Metropolitan Area Networks.  This is an experimental, not recommended
  990. standard.  Distribution of this memo is unlimited.
  991.  
  992. .ti 0
  993. Overview and Rational
  994.  
  995. Avian carriers can provide high delay, low throughput, and low
  996. altitude service.  The connection topology is limited to a single
  997. point-to-point path for each carrier, used with standard carriers, but
  998. many carriers can be used without significant interference with each
  999. other, outside of early spring.  This is because of the 3D ether space
  1000. available to the carriers, in contrast to the 1D ether used by
  1001. IEEE802.3.  The carriers have an intrinsic collision avoidance system,
  1002. which increases availability.  Unlike some network technologies, such
  1003. as packet radio, communication is not limited to line-of-sight
  1004. distance.  Connection oriented service is available in some cities,
  1005. usually based upon a central hub topology.
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Postel & Reynolds            Informational                     [Page 18]
  1011.  
  1012. RFC 2223              Instructions to RFC Authors           October 1997
  1013.  
  1014.  
  1015. .ti 0
  1016. Frame Format
  1017.  
  1018. The IP datagram is printed, on a small scroll of paper, in
  1019. hexadecimal, with each octet separated by whitestuff and blackstuff.
  1020. The scroll of paper is wrapped around one leg of the avian carrier.
  1021. A band of duct tape is used to secure the datagram's edges.  The
  1022. bandwidth is limited to the leg length.  The MTU is variable, and
  1023. paradoxically, generally increases with increased carrier age.  A
  1024. typical MTU is 256 milligrams.  Some datagram padding may be needed.
  1025.  
  1026. Upon receipt, the duct tape is removed and the paper copy of the
  1027. datagram is optically scanned into a electronically transmittable
  1028. form.
  1029.  
  1030. .ti 0
  1031. Discussion
  1032.  
  1033. Multiple types of service can be provided with a prioritized pecking
  1034. order.  An additional property is built-in worm detection and
  1035. eradication.  Because IP only guarantees best effort delivery, loss of
  1036. a carrier can be tolerated.  With time, the carriers are
  1037. self-regenerating.  While broadcasting is not specified, storms can
  1038. cause data loss.  There is persistent delivery retry, until the
  1039. carrier drops.  Audit trails are automatically generated, and can
  1040. often be found on logs and cable trays.
  1041.  
  1042. .ti 0
  1043. Security Considerations
  1044.  
  1045. .in 3
  1046. Security is not generally a problem in normal operation, but special
  1047. measures must be taken (such as data encryption) when avian carriers
  1048. are used in a tactical environment.
  1049.  
  1050. .ti 0
  1051. Author's Address
  1052.  
  1053. .nf
  1054. David Waitzman
  1055. BBN Systems and Technologies Corporation
  1056. BBN Labs Division
  1057. 10 Moulton Street
  1058. Cambridge, MA 02238
  1059.  
  1060. Phone: (617) 873-4323
  1061.  
  1062. EMail: dwaitzman@BBN.COM
  1063.  
  1064.  
  1065.  
  1066. Postel & Reynolds            Informational                     [Page 19]
  1067.  
  1068. RFC 2223              Instructions to RFC Authors           October 1997
  1069.  
  1070.  
  1071. 21.  Full Copyright Statement
  1072.  
  1073.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  1074.  
  1075.    This document and translations of it may be copied and furnished to
  1076.    others, and derivative works that comment on or otherwise explain it
  1077.    or assist in its implmentation may be prepared, copied, published and
  1078.    distributed, in whole or in part, without restriction of any kind,
  1079.    provided that the above copyright notice and this paragraph are
  1080.    included on all such copies and derivative works.  However, this
  1081.    document itself may not be modified in any way, such as by removing
  1082.    the copyright notice or references to the Internet Society or other
  1083.    Internet organizations, except as needed for the purpose of
  1084.    developing Internet standards in which case the procedures for
  1085.    copyrights defined in the Internet Standards process must be
  1086.    followed, or as required to translate it into languages other than
  1087.    English.
  1088.  
  1089.    The limited permissions granted above are perpetual and will not be
  1090.    revoked by the Internet Society or its successors or assigns.
  1091.  
  1092.    This document and the information contained herein is provided on an
  1093.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1094.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1095.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1096.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1097.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Postel & Reynolds            Informational                     [Page 20]
  1123.  
  1124.