Movatterモバイル変換

Network Working Group                                          J. PostelRequest for Comments: 2223                                   J. ReynoldsObsoletes:1543,1111,825                                           ISICategory: Informational                                     October 1997Instructions to RFC AuthorsStatus of this Memo   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.Copyright Notice   Copyright (C) The Internet Society (1997).  All Rights Reserved.Table of Contents1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .22.   Editorial Policy . . . . . . . . . . . . . . . . . . . . . .33.   Format Rules . . . . . . . . . . . . . . . . . . . . . . . .4   3a.   ASCII Format Rules  . . . . . . . . . . . . . . . . . . . .5   3b.   PostScript Format Rules . . . . . . . . . . . . . . . . . .64.   Header . . . . . . . . . . . . . . . . . . . . . . . . . . .7   4a.   First Page Heading  . . . . . . . . . . . . . . . . . . . .7   4b.   Running Header  . . . . . . . . . . . . . . . . . . . . . .8   4c.   Running Footer  . . . . . . . . . . . . . . . . . . . . . .85.   Status Section . . . . . . . . . . . . . . . . . . . . . . .86.   Copyright Notice . . . . . . . . . . . . . . . . . . . . . .97.   Introduction Section . . . . . . . . . . . . . . . . . . . .98.   References Section . . . . . . . . . . . . . . . . . . . .119.   Security Considerations Section  . . . . . . . . . . . . .1110.  Author's Address Section . . . . . . . . . . . . . . . . .1111.  Copyright Section  . . . . . . . . . . . . . . . . . . . .1112.  Relation to other RFCs . . . . . . . . . . . . . . . . . .1213.  Protocol Standards Process . . . . . . . . . . . . . . . .1314.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .1315.  Distribution Lists . . . . . . . . . . . . . . . . . . . .1416.  RFC Index  . . . . . . . . . . . . . . . . . . . . . . . .1417.  Security Considerations  . . . . . . . . . . . . . . . . .1418.  References . . . . . . . . . . . . . . . . . . . . . . . .1419.  Authors' Addresses . . . . . . . . . . . . . . . . . . . .1520.  Appendix - RFC "nroff macros"  . . . . . . . . . . . . . .1621.  Full Copyright Statement . . . . . . . . . . . . . . . . .20Postel & Reynolds            Informational                      [Page 1]

RFC 2223              Instructions to RFC Authors           October 19971.  Introduction   This Request for Comments (RFC) provides information about the   preparation of RFCs, and certain policies relating to the publication   of RFCs.   The RFC series of notes covers a broad range of interests.  The core   topics are the Internet and the TCP/IP protocol suite.  However, any   topic related to computer communication may be acceptable at the   discretion of the RFC Editor.   Memos proposed to be RFCs may be submitted by anyone.  One large   source of memos that become RFCs is the Internet Engineering Task   Force (IETF).  The IETF working groups (WGs) evolve their working   memos (known as Internet Drafts or I-Ds) until they feel they are   ready for publication, then the memos are reviewed by the Internet   Engineering Steering Group (IESG), and if approved sent by the IESG   to the RFC Editor.   Most of the memos submitted to the RFC Editor from independent   sources will be reviewed by the IESG for possible relationship to   work in progress in the IETF Working Groups.   RFCs are distributed online by being stored as public access files,   and a short message is sent to the distribution list indicating the   availability of the memo.   The online files are copied by the interested people and printed or   displayed at their site on their equipment.  This means that the   format of the online files must meet the constraints of a wide   variety of printing and display equipment.  (RFCs may also be   returned via e-mail in response to an e-mail query, or RFCs may be   found using information and database searching tools such as Gopher,   Wais, or the World Wide Web (WWW).   RFCs have been traditionally published and continue to be published   in ASCII text.   While the primary RFCs is always an ASCII text file, secondary or   alternative versions of RFC may be provided in PostScript.  This   decision is motivated by the desire to include diagrams, drawings,   and such in RFCs.  PostScript documents (on paper only, so far) are   visually more appealing and have better readability.   PostScript was chosen for the fancy form of RFC publication over   other possible systems (e.g., impress, interpress, oda) because of   the perceived wide spread availability of PostScript capable   printers.Postel & Reynolds            Informational                      [Page 2]

RFC 2223              Instructions to RFC Authors           October 1997   However, many RFC users read the documents online and use various   text oriented tools (e.g., emacs, grep) to search them.  Often, brief   excerpts from RFCs are included in e-mail.  These practices are not   yet practical with PostScript files.   PostScript producing systems are less standard than is desirable and   that several of the document production systems that claim to produce   PostScript actually produce nonstandard results.   In the future, it may be necessary to identify a set of document   production systems authorized for use in production of PostScript   RFCs, based on the reasonableness of the output files they generate.2.  Editorial Policy   Documents proposed to be RFCs are reviewed by the RFC Editor and   possibly by other reviewers he selects.   The result of the review may be to suggest to the author some   improvements to the document before publication.   Occasionally, it may be apparent that the topic of a proposed RFC is   also the subject of an IETF Working Group, and that the author could   coordinate with the working group to the advantage of both.  The   usual result of this is that a revised memo is produced as a working   group Internet Draft and eventually emerges from the IETF process as   a recommendation from the IESG to the RFC Editor.   In some cases it may be determined that the submitted document is not   appropriate material to be published as an RFC.   In some cases it may be necessary to include in the document a   statement based on the reviews about the ideas in the document.  This   may be done in the case that the document suggests relevant but   inappropriate or unsafe ideas, and other situations.   The RFC Editor may make minor changes to the document, especially in   the areas of style and format, but on some occasions also to the   text.  Sometimes the RFC Editor will undertake to make more   significant changes, especially when the format rules (see below) are   not followed.  However, more often the memo will be returned to the   author for the additional work.   Documents intended to become RFCs specifying standards track   protocols must be approved by the IESG before being sent to the RFC   Editor.  The established procedure is that when the IESG completes   work on a document that is to become a standards track RFC the   communication will be from the Secretary of the IESG to the RFCPostel & Reynolds            Informational                      [Page 3]

RFC 2223              Instructions to RFC Authors           October 1997   Editor.  Generally, the documents in question are Internet Drafts.   The communication usually cites the exact Internet Draft in question   (by file name).  The RFC Editor must assume that only that file is to   be processed to become the RFC.  If the authors have small   corrections to the text, they should be sent to the RFC Editor   separately (or as a "diff"), authors should not send a new version of   the document.   In some cases, authors prepare alternate secondary versions of RFCs   in fancy format using PostScript.  Since the ASCII text version of   the RFC is the primary version, the PostScript version must match the   text version.  The RFC Editor must decide if the PostScript version   is "the same as" the ASCII version before the PostScript version can   be published.   The effect of this is that the RFC Editor first processes the ASCII   version of the memo through to publication as an RFC.  If the author   wishes to submit a PostScript version at that point that matches the   ASCII version (and the RFC Editor agrees that it does), then the   PostScript version will be installed in the RFC repositories and   announced to the community.   Due to various time pressures on the RFC Editorial staff, the time   elapsed between submission and publication can vary greatly.  It is   always acceptable to query (ping) the RFC Editor about the status of   an RFC during this time (but not more than once a week).  The two   weeks preceding an IETF meeting are generally very busy, so RFCs   submitted shortly before an IETF meeting are most likely to be   published after the meeting.3.  Format Rules   To meet the distribution constraints, the following rules are   established for the two allowed formats for RFCs:  ASCII and   PostScript.   The RFC Editor attempts to ensure a consistent RFC style.  To do this   the RFC Editor may choose to reformat the RFC submitted.  It is much   easier to do this if the submission matches the style of the most   recent RFCs.  Please do look at some recent RFCs and prepare yours in   the same style.   You must submit an editable online document to the RFC Editor.  The   RFC Editor may require or make minor changes in format or style and   will insert the actual RFC number.Postel & Reynolds            Informational                      [Page 4]

RFC 2223              Instructions to RFC Authors           October 1997   Most of the RFCs are processed by the RFC Editor with the unix   "nroff" program using a very simple set of the formatting commands   (or "requests") from the "ms" macro package (see the Appendix).  If a   memo submitted to be an RFC has been prepared by the author using   nroff, it is very helpful to let the RFC Editor know that when it is   submitted.   3a.  ASCII Format Rules      The character codes are ASCII.      Each page must be limited to 58 lines followed by a form feed on a      line by itself.      Each line must be limited to 72 characters followed by carriage      return and line feed.      No overstriking (or underlining) is allowed.      These "height" and "width" constraints include any headers,      footers, page numbers, or left side indenting.      Do not fill the text with extra spaces to provide a straight right      margin.      Do not do hyphenation of words at the right margin.      Do not use footnotes.  If such notes are necessary, put them at      the end of a section, or at the end of the document.      Use single spaced text within a paragraph, and one blank line      between paragraphs.      Note that the number of pages in a document and the page numbers      on which various sections fall will likely change with      reformatting.  Thus cross references in the text by section number      usually are easier to keep consistent than cross references by      page number.      RFCs in ASCII Format may be submitted to the RFC Editor in e-mail      messages (or as online files) in either the finished publication      format or in nroff.  If you plan to submit a document in nroff      please consult the RFC Editor first.Postel & Reynolds            Informational                      [Page 5]

RFC 2223              Instructions to RFC Authors           October 1997   3b.  PostScript Format Rules      Standard page size is 8 1/2 by 11 inches.      Margin of 1 inch on all sides (top, bottom, left, and right).      Main text should have a point size of no less than 10 points with      a line spacing of 12 points.      Footnotes and graph notations no smaller than 8 points with a line      spacing of 9.6 points.      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.      Prepare diagrams and images based on lowest common denominator      PostScript.  Consider common PostScript printer functionality and      memory requirements.      The following PostScript commands should not be used:      initgraphics, erasepage, copypage, grestoreall, initmatrix,      initclip, banddevice, framedevice, nulldevice and renderbands.      Note that the number of pages in a document and the page numbers      on which various sections fall will likely differ in the ASCII and      the PostScript versions.  Thus cross references in the text by      section number usually are easier to keep consistent than cross      references by page number.      These PostScript rules are likely to changed and expanded as      experience is gained.      RFCs in PostScript Format may be submitted to the RFC Editor in      e-mail messages (or as online files).  If you plan to submit a      document in PostScript please consult the RFC Editor first.      Note that since the ASCII text version of the RFC is the primary      version, the PostScript version must match the text version.  The      RFC Editor must decide if the PostScript version is "the same as"      the ASCII version before the PostScript version can be published.Postel & Reynolds            Informational                      [Page 6]

RFC 2223              Instructions to RFC Authors           October 19974.  Headers and Footers   There is the first page heading, the running headers, and the running   footers.   4a.  First Page      Please see the front page of this memo for an example of the front      page heading.  On the first page there is no running header.  The      top of the first page has the following items:      Network Working Group         The traditional heading for the group that founded the RFC         series.  This appears on the first line on the left hand side         of the heading.      Request for Comments: nnnn         Identifies this as a request for comments and specifies the         number.  Indicated on the second line on the left side.  The         actual number is filled in at the last moment before         publication by the RFC Editor.      Author         The author's name (first initial and last name only) indicated         on the first line on the right side of the heading.      Organization         The author's organization, indicated on the second line on the         right side.      Date         This is the Month and Year of the RFC Publication. Indicated on         the third line on the right side.      Updates or Obsoletes         If this RFC Updates or Obsoletes another RFC, this is indicated         as third line on the left side of the heading.Postel & Reynolds            Informational                      [Page 7]

RFC 2223              Instructions to RFC Authors           October 1997      Category         The category of this RFC, one of: Standards Track, Best Current         Practice, Informational, or Experimental.  This is indicated on         the third (if there is no Updates or Obsoletes indication) or         fourth line of the left side.      Other Numbers         Other numbers in the RFC series of notes include the subseries         of FYI (For Your Information) [4], BCP (Best Current Practice)         [5], and STD (Standard) [6].  These are placed on the left         side.      Title         The title appears, centered, below the rest of the heading.         Periods or "dots" in the titles are not allowed.      If there are multiple authors and if the multiple authors are from      multiple organizations the right side heading may have additional      lines to accommodate them and to associate the authors with the      organizations properly.   4b.  Running Headers      The running header in one line (on page 2 and all subsequent      pages) has the RFC number on the left (RFC NNNN), the (possibly      nshortened form) title centered, and the date (Month Year) on the      right.   4c.  Running Footers      The running footer in one line (on all pages) has the author's      last name on the left, category centered, and the page number on      the right ([Page N]).5.  Status Section   Each RFC must include on its first page the "Status of this Memo"   section which contains two elements: (1) a paragraph describing the   type of the RFC, and (2) the distribution statement.   The content of this section will be one of the four following   statements.Postel & Reynolds            Informational                      [Page 8]

RFC 2223              Instructions to RFC Authors           October 1997   Standards Track      "This document specifies an Internet standards track protocol for      the Internet community, and requests discussion and suggestions      for improvements.  Please refer to the current edition of the      "Internet Official Protocol Standards" (STD 1) for the      standardization state and status of this protocol.  Distribution      of this memo is unlimited."   Best Current Practice      "This document specifies an Internet Best Current Practices for      the Internet Community, and requests discussion and suggestions      for improvements.  Distribution of this memo is unlimited."   Experimental      "This memo defines an Experimental Protocol for the Internet      community.  This memo does not specify an Internet standard of any      kind.  Discussion and suggestions for improvement are requested.      Distribution of this memo is unlimited."   Informational      "This memo provides information for the Internet community.  This      memo does not specify an Internet standard of any kind.      Distribution of this memo is unlimited."6.  Copyright Notice   Immediately following the Status section the statement, "Copyright   (C) The Internet Society (date).  All Rights Reserved." is placed.   Also, seeSection 11 for the full statement that must appear at the   end of the document.7.  Introduction Section   Each RFC should have an Introduction section that (among other   things) explains the motivation for the RFC and (if appropriate)   describes the applicability of the protocol described.      Normally, this will be the "abstract" section from the Internet      Draft.  If the RFC is not based on an I-D, other possibilities      are:Postel & Reynolds            Informational                      [Page 9]

RFC 2223              Instructions to RFC Authors           October 1997         Protocol            This protocol is intended to provide the bla-bla service,            and be used between clients and servers on host computers.            Typically the clients are on workstation hosts and the            servers on mainframe hosts.            or            This protocol is intended to provide the bla-bla service,            and be used between special purpose units such as terminal            servers or routers and a monitoring host.         Discussion            The purpose of this RFC is to focus discussion on particular            problems in the Internet and possible methods of solution.            No proposed solutions in this document are intended as            standards for the Internet.  Rather, it is hoped that a            general consensus will emerge as to the appropriate solution            to such problems, leading eventually to the adoption of            standards.         Interest            This RFC is being distributed to members of the Internet            community in order to solicit their reactions to the            proposals contained in it.  While the issues discussed may            not be directly relevant to the research problems of the            Internet, they may be interesting to a number of researchers            and implementers.         Status Report            In response to the need for maintenance of current            information about the status and progress of various            projects in the Internet community, this RFC is issued for            the benefit of community members.  The information contained            in this document is accurate as of the date of publication,            but is subject to change.  Subsequent RFCs will reflect such            changes.      These paragraphs need not be followed word for word, but the      general intent of the RFC must be made clear.Postel & Reynolds            Informational                     [Page 10]

RFC 2223              Instructions to RFC Authors           October 19978.  References Section   Nearly all RFCs contain citations to other documents, and these are   listed in a References section near the end of the RFC.  There are   many styles for references, and the RFCs have one of their own.   Please follow the reference style used in recent RFCs.  See the   reference section of this RFC for an example.  Please note that for   protocols that have been assigned STD numbers, the STD number must be   included in the reference.   In many standards track documents several words are used to signify   the requirements in the specification.  These words are often   capitalized.BCP 14,RFC 2119 [3], defines these words as they   should be interpreted in IETF documents.9.  Security Considerations Section   All RFCs must contain a section near the end of the document that   discusses the security considerations of the protocol or procedures   that are the main topic of the RFC.10.  Author's Address Section   Each RFC must have at the very end a section giving the author's   address, including the name and postal address, the telephone number,   (optional: a FAX number) and the Internet email address.11.  Copyright Section   PerBCP 9,RFC 2026 [2], "The following copyright notice and   disclaimer shall be included in all ISOC standards-related   documentation."  The following statement should be placed on the last   page of the RFC, as the "Full Copyright Statement".      "Copyright (C) The Internet Society (date).  All Rights Reserved.      This document and translations of it may be copied and furnished      to others, and derivative works that comment on or otherwise      explain it or assist in its implementation may be prepared, copied,      published and distributed, in whole or in part, without      restriction of any kind, provided that the above copyright notice      and this paragraph are included on all such copies and derivative      works.  However, this document itself may not be modified in any      way, such as by removing the copyright notice or references to the      Internet Society or other Internet organizations, except as needed      for the purpose of developing Internet standards in which case the      procedures for copyrights defined in the Internet Standards      process must be followed, or as required to translate it intoPostel & Reynolds            Informational                     [Page 11]

RFC 2223              Instructions to RFC Authors           October 1997      languages other than English.      The limited permissions granted above are perpetual and will not      be revoked by the Internet Society or its successors or assigns.      This document and the information contained herein is provided on      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.12.  Relation to other RFCs   Sometimes an RFC adds information on a topic discussed in a previous   RFC or completely replaces an earlier RFC.  There are two terms used   for these cases respectively, Updates and Obsoletes.  A document that   obsoletes an earlier document can stand on its own.  A document that   merely updates an earlier document cannot stand on its own; it is   something that must be added to or inserted into the previously   existing document, and has limited usefulness independently.  The   terms Supercedes and Replaces are no longer used.   Updates      To be used as a reference from a new item that cannot be used      alone (i.e., one that supplements a previous document), to refer      to the previous document.  The newer publication is a part that      will supplement or be added on to the existing document; e.g., an      addendum, or separate, extra information that is to be added to      the original document.   Obsoletes      To be used to refer to an earlier document that is replaced by      this document.  This document contains either revised information,      or else all of the same information plus some new information,      however extensive or brief that new information is; i.e., this      document can be used alone, without reference to the older      document.Postel & Reynolds            Informational                     [Page 12]

RFC 2223              Instructions to RFC Authors           October 1997      For example:         On the Assigned Numbers RFCs the term Obsoletes should be used         since the new document actually incorporate new information         (however brief) into the text of existing information and is         more up-to-date than the older document, and hence, replaces it         and makes it Obsoletes.   In lists of RFCs or the RFC-Index (but not on the RFCs themselves)   the following may be used with early documents to point to later   documents.   Obsoleted-by      To be used to refer to the newer document(s) that replaces the      older document.   Updated-by      To be used to refer to the newer section(s) which are to be added      to the existing, still used, document.13.  Protocol Standards Process   See the current "Internet Official Protocol Standards" (STD 1) memo   for the definitive statement on protocol standards and their   publication [1].   The established procedure is that when the IESG completes work on a   document that is to become a standards track RFC the communication   will be from the Secretary of the IESG to the RFC Editor.  Generally,   the documents in question are Internet Drafts.  The communication   usually cites the exact Internet Draft (by file name) in question.   The RFC Editor must assume that only that file is to be processed to   become the RFC.  If the authors have small corrections to the text,   they should be sent to the RFC Editor separately (or as a "diff"), do   not send a new version of the document.14.  Contact   To contact the RFC Editor send an email message to:         "rfc-editor@isi.edu".Postel & Reynolds            Informational                     [Page 13]

RFC 2223              Instructions to RFC Authors           October 199715.  Distribution Lists   The RFC announcements are distributed via two mailing lists: the   "IETF-Announce" list, and the "RFC-DIST" list.  You don't want to be   on both lists.   To join (or quit) the IETF-Announce list send a message to ietf-   request@ietf.org.   To join (or quit) the RFC-DIST list send a message to rfc-dist-   request@isi.edu.16.  RFC Index   Several organizations maintain RFC Index files, generally using the   file name "rfc-index.txt".  The contents of such a file copied from   one site may not be identical to that copied from another site.17.  Security Considerations   This RFC raises no security issues (however, seeSection 9).18.  References   [1]  Postel, J., Editor, "Internet Official Protocol Standards", STD        1,RFC 2200, June 1997.   [2]  Bradner, S., "The Internet Standards Process -- Revision 3",BCP9,RFC 2026, October 1996.   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.   [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.Postel & Reynolds            Informational                     [Page 14]

RFC 2223              Instructions to RFC Authors           October 199719.  Authors' Addresses   Jon Postel   USC/Information Sciences Institute   4676 Admiralty Way   Marina del Rey, CA  90292   Phone: +1 310-822-1511   Fax:   +1 310-823-6714   EMail: Postel@ISI.EDU   Joyce K. Reynolds   USC/Information Sciences Institute   4676 Admiralty Way   Marina del Rey, CA  90292   Phone: +1 310-822-1511   Fax:   +1 310-823-6714   EMail: jkrey@isi.eduPostel & Reynolds            Informational                     [Page 15]

RFC 2223              Instructions to RFC Authors           October 199720.  Appendix - RFC "nroff macros"   Generally, we use the very simplest nroff features.  We use the "ms"   macros.  So, "nroff -ms input-file > output-file".  However, we could   not get nroff to do the right thing about putting a form feed after   the last visible line on a page and no extra line feeds before the   first visible line of the next page.  We want:        last visible line on page i        ^L        first visible line on page i+1   So, we invented a hack to fix this.  We use a perl script called   "fix.pl".  So the command to process the file becomes:        nroff -ms input-file | fix.pl > output-file   The actual perl script is:#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#! /local/bin/perl# fix.pl  17-Nov-93  Craig Milo Rogers at USC/ISI##       The style guide for RFCs calls for pages to be delimited by the# sequence <last-non-blank-line><formfeed-line><first-non-blank-line>.# Unfortunately, NROFF is reluctant to produce output that conforms to# this convention.  This script fixes RFC-style documents by searching# for the token "FORMFEED[Page", replacing "FORMFEED" with spaces,# appending a formfeed line, and deleting white space up to the next# non-white space character.##       There is one difference between this script's output and that of# the "fix.sh" and "pg" programs it replaces:  this script includes a# newline after the formfeed after the last page in a file, whereas the# earlier programs left a bare formfeed as the last character in the# file.  To obtain bare formfeeds, uncomment the second substitution# command below.  To strip the final formfeed, uncomment the third# substitution command below.##       This script is intended to run as a filter, as in:## nroff -ms input-file | fix.pl > output-file##       When porting this script, please observe the following points:## 1)    ISI keeps perl in "/local/bin/perl";  your system may keep itPostel & Reynolds            Informational                     [Page 16]

RFC 2223              Instructions to RFC Authors           October 1997#       elsewhere.# 2)    On systems with a CRLF end-of-line convention, the "\n"s below#       may have to be replaced with "\r\n"s.$* = 1;                                 # Enable multiline patterns.undef $/;                               # Read whole files in a single                                        # gulp.while (<>) {                            # Read the entire input file.    s/FORMFEED(\[Page\s+\d+\])\s+/        \1\n\f\n/g;                                        # Rewrite the end-of-pages.#    s/\f\n$/\f/;                       # Want bare formfeed at end?#    s/\f\n$//;                         # Want no formfeed at end?    print;                              # Print the resultant file.}#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   This script can also be copied from:ftp://ftp.isi.edu/in-notes/rfc-editor/fix.pl   Now as to the nroff features we actually use, following is a sample   memo, prepared in RFC style.Postel & Reynolds            Informational                     [Page 17]

RFC 2223              Instructions to RFC Authors           October 1997.pl 10.0i.po 0.ll 7.2i.lt 7.2i.nr LL 7.2i.nr LT 7.2i.ds LF Waitzman.ds RF PUTFFHERE[Page %].ds CF.ds LHRFC 1149.ds RH 1 April 1990.ds CH IP Datagrams on Avian Carriers.hy 0.ad l.in 0Network Working Group                                        D. WaitzmanRequest for Comments: 1149                                       BBN STC                                                            1 April 1990.ceA Standard for the Transmission of IP Datagrams on Avian Carriers.ti 0Status of this Memo.fi.in 3This memo describes an experimental method for the encapsulation of IPdatagrams in avian carriers.  This specification is primarily usefulin Metropolitan Area Networks.  This is an experimental, not recommendedstandard.  Distribution of this memo is unlimited..ti 0Overview and RationalAvian carriers can provide high delay, low throughput, and lowaltitude service.  The connection topology is limited to a singlepoint-to-point path for each carrier, used with standard carriers, butmany carriers can be used without significant interference with eachother, outside of early spring.  This is because of the 3D ether spaceavailable to the carriers, in contrast to the 1D ether used byIEEE802.3.  The carriers have an intrinsic collision avoidance system,which increases availability.  Unlike some network technologies, suchas packet radio, communication is not limited to line-of-sightdistance.  Connection oriented service is available in some cities,usually based upon a central hub topology.Postel & Reynolds            Informational                     [Page 18]

RFC 2223              Instructions to RFC Authors           October 1997.ti 0Frame FormatThe IP datagram is printed, on a small scroll of paper, inhexadecimal, with each octet separated by whitestuff and blackstuff.The scroll of paper is wrapped around one leg of the avian carrier.A band of duct tape is used to secure the datagram's edges.  Thebandwidth is limited to the leg length.  The MTU is variable, andparadoxically, generally increases with increased carrier age.  Atypical MTU is 256 milligrams.  Some datagram padding may be needed.Upon receipt, the duct tape is removed and the paper copy of thedatagram is optically scanned into a electronically transmittableform..ti 0DiscussionMultiple types of service can be provided with a prioritized peckingorder.  An additional property is built-in worm detection anderadication.  Because IP only guarantees best effort delivery, loss ofa carrier can be tolerated.  With time, the carriers areself-regenerating.  While broadcasting is not specified, storms cancause data loss.  There is persistent delivery retry, until thecarrier drops.  Audit trails are automatically generated, and canoften be found on logs and cable trays..ti 0Security Considerations.in 3Security is not generally a problem in normal operation, but specialmeasures must be taken (such as data encryption) when avian carriersare used in a tactical environment..ti 0Author's Address.nfDavid WaitzmanBBN Systems and Technologies CorporationBBN Labs Division10 Moulton StreetCambridge, MA 02238Phone: (617) 873-4323EMail: dwaitzman@BBN.COMPostel & Reynolds            Informational                     [Page 19]

RFC 2223              Instructions to RFC Authors           October 199721.  Full Copyright Statement   Copyright (C) The Internet Society (1997).  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 implmentation 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."Postel & Reynolds            Informational                     [Page 20]