summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2223.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2223.txt')
-rw-r--r--doc/rfc/rfc2223.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc2223.txt b/doc/rfc/rfc2223.txt
new file mode 100644
index 0000000..e1e7484
--- /dev/null
+++ b/doc/rfc/rfc2223.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group J. Postel
+Request for Comments: 2223 J. Reynolds
+Obsoletes: 1543, 1111, 825 ISI
+Category: Informational October 1997
+
+
+ Instructions to RFC Authors
+
+Status 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 Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3a. ASCII Format Rules . . . . . . . . . . . . . . . . . . . . 5
+ 3b. PostScript Format Rules . . . . . . . . . . . . . . . . . . 6
+ 4. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4a. First Page Heading . . . . . . . . . . . . . . . . . . . . 7
+ 4b. Running Header . . . . . . . . . . . . . . . . . . . . . . 8
+ 4c. Running Footer . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Status Section . . . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. Introduction Section . . . . . . . . . . . . . . . . . . . . 9
+ 8. References Section . . . . . . . . . . . . . . . . . . . . 11
+ 9. Security Considerations Section . . . . . . . . . . . . . 11
+ 10. Author's Address Section . . . . . . . . . . . . . . . . . 11
+ 11. Copyright Section . . . . . . . . . . . . . . . . . . . . 11
+ 12. Relation to other RFCs . . . . . . . . . . . . . . . . . . 12
+ 13. Protocol Standards Process . . . . . . . . . . . . . . . . 13
+ 14. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 15. Distribution Lists . . . . . . . . . . . . . . . . . . . . 14
+ 16. RFC Index . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 17. Security Considerations . . . . . . . . . . . . . . . . . 14
+ 18. References . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
+ 20. Appendix - RFC "nroff macros" . . . . . . . . . . . . . . 16
+ 21. Full Copyright Statement . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+Postel & Reynolds Informational [Page 1]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+1. 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 RFC
+
+
+
+Postel & 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 1997
+
+
+4. Headers and Footers
+
+ There is the first page heading, the running headers, and the running
+ footers.
+
+ 4a. First Page
+
+ Please see the front page of this memo for an example of the front
+ page heading. On the first page there is no running header. The
+ top of the first page has the following items:
+
+ Network Working Group
+
+ The traditional heading for the group that founded the RFC
+ series. This appears on the first line on the left hand side
+ of the heading.
+
+ Request for Comments: nnnn
+
+ Identifies this as a request for comments and specifies the
+ number. Indicated on the second line on the left side. The
+ actual number is filled in at the last moment before
+ publication by the RFC Editor.
+
+ 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, see Section 11 for the full statement that must appear at the
+ end of the document.
+
+7. Introduction Section
+
+ Each RFC should have an Introduction section that (among other
+ things) explains the motivation for the RFC and (if appropriate)
+ describes the applicability of the protocol described.
+
+ Normally, this will be the "abstract" section from the Internet
+ Draft. If the RFC is not based on an I-D, other possibilities
+ are:
+
+
+
+
+
+
+
+Postel & Reynolds Informational [Page 9]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+ Protocol
+
+ This protocol is intended to provide the bla-bla service,
+ and be used between clients and servers on host computers.
+ Typically the clients are on workstation hosts and the
+ servers on mainframe hosts.
+
+ or
+
+ This protocol is intended to provide the bla-bla service,
+ and be used between special purpose units such as terminal
+ servers or routers and a monitoring host.
+
+ Discussion
+
+ The purpose of this RFC is to focus discussion on particular
+ problems in the Internet and possible methods of solution.
+ No proposed solutions in this document are intended as
+ standards for the Internet. Rather, it is hoped that a
+ general consensus will emerge as to the appropriate solution
+ to such problems, leading eventually to the adoption of
+ standards.
+
+ Interest
+
+ This RFC is being distributed to members of the Internet
+ community in order to solicit their reactions to the
+ proposals contained in it. While the issues discussed may
+ not be directly relevant to the research problems of the
+ Internet, they may be interesting to a number of researchers
+ and implementers.
+
+ Status Report
+
+ In response to the need for maintenance of current
+ information about the status and progress of various
+ projects in the Internet community, this RFC is issued for
+ the benefit of community members. The information contained
+ in this document is accurate as of the date of publication,
+ but is subject to change. Subsequent RFCs will reflect such
+ changes.
+
+ These paragraphs need not be followed word for word, but the
+ general intent of the RFC must be made clear.
+
+
+
+
+
+
+
+Postel & Reynolds Informational [Page 10]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+8. References Section
+
+ Nearly all RFCs contain citations to other documents, and these are
+ listed in a References section near the end of the RFC. There are
+ many styles for references, and the RFCs have one of their own.
+ Please follow the reference style used in recent RFCs. See the
+ reference section of this RFC for an example. Please note that for
+ protocols that have been assigned STD numbers, the STD number must be
+ included in the reference.
+
+ In many standards track documents several words are used to signify
+ the requirements in the specification. These words are often
+ capitalized. BCP 14, RFC 2119 [3], defines these words as they
+ should be interpreted in IETF documents.
+
+9. Security Considerations Section
+
+ All RFCs must contain a section near the end of the document that
+ discusses the security considerations of the protocol or procedures
+ that are the main topic of the RFC.
+
+10. Author's Address Section
+
+ Each RFC must have at the very end a section giving the author's
+ address, including the name and postal address, the telephone number,
+ (optional: a FAX number) and the Internet email address.
+
+11. Copyright Section
+
+ Per BCP 9, RFC 2026 [2], "The following copyright notice and
+ disclaimer shall be included in all ISOC standards-related
+ documentation." The following statement should be placed on the last
+ page of the RFC, as the "Full Copyright Statement".
+
+ "Copyright (C) The Internet Society (date). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished
+ to others, and derivative works that comment on or otherwise
+ explain it or assist in its implementation may be prepared, copied,
+ published and distributed, in whole or in part, without
+ restriction of any kind, provided that the above copyright notice
+ and this paragraph are included on all such copies and derivative
+ works. However, this document itself may not be modified in any
+ way, such as by removing the copyright notice or references to the
+ Internet Society or other Internet organizations, except as needed
+ for the purpose of developing Internet standards in which case the
+ procedures for copyrights defined in the Internet Standards
+ process must be followed, or as required to translate it into
+
+
+
+Postel & Reynolds Informational [Page 11]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+ languages other than English.
+
+ The limited permissions granted above are perpetual and will not
+ be revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on
+ an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+12. Relation to other RFCs
+
+ Sometimes an RFC adds information on a topic discussed in a previous
+ RFC or completely replaces an earlier RFC. There are two terms used
+ for these cases respectively, Updates and Obsoletes. A document that
+ obsoletes an earlier document can stand on its own. A document that
+ merely updates an earlier document cannot stand on its own; it is
+ something that must be added to or inserted into the previously
+ existing document, and has limited usefulness independently. The
+ terms Supercedes and Replaces are no longer used.
+
+ Updates
+
+ To be used as a reference from a new item that cannot be used
+ alone (i.e., one that supplements a previous document), to refer
+ to the previous document. The newer publication is a part that
+ will supplement or be added on to the existing document; e.g., an
+ addendum, or separate, extra information that is to be added to
+ the original document.
+
+ Obsoletes
+
+ To be used to refer to an earlier document that is replaced by
+ this document. This document contains either revised information,
+ or else all of the same information plus some new information,
+ however extensive or brief that new information is; i.e., this
+ document can be used alone, without reference to the older
+ document.
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds Informational [Page 12]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+ For example:
+
+ On the Assigned Numbers RFCs the term Obsoletes should be used
+ since the new document actually incorporate new information
+ (however brief) into the text of existing information and is
+ more up-to-date than the older document, and hence, replaces it
+ and makes it Obsoletes.
+
+ In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
+ the following may be used with early documents to point to later
+ documents.
+
+ Obsoleted-by
+
+ To be used to refer to the newer document(s) that replaces the
+ older document.
+
+ Updated-by
+
+ To be used to refer to the newer section(s) which are to be added
+ to the existing, still used, document.
+
+13. Protocol Standards Process
+
+ See the current "Internet Official Protocol Standards" (STD 1) memo
+ for the definitive statement on protocol standards and their
+ publication [1].
+
+ The established procedure is that when the IESG completes work on a
+ document that is to become a standards track RFC the communication
+ will be from the Secretary of the IESG to the RFC Editor. Generally,
+ the documents in question are Internet Drafts. The communication
+ usually cites the exact Internet Draft (by file name) in question.
+ The RFC Editor must assume that only that file is to be processed to
+ become the RFC. If the authors have small corrections to the text,
+ they should be sent to the RFC Editor separately (or as a "diff"), do
+ not send a new version of the document.
+
+14. Contact
+
+ To contact the RFC Editor send an email message to:
+
+ "rfc-editor@isi.edu".
+
+
+
+
+
+
+
+
+Postel & Reynolds Informational [Page 13]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+15. Distribution Lists
+
+ The RFC announcements are distributed via two mailing lists: the
+ "IETF-Announce" list, and the "RFC-DIST" list. You don't want to be
+ on both lists.
+
+ To join (or quit) the IETF-Announce list send a message to ietf-
+ 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, see Section 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", 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.
+
+ [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 1997
+
+
+19. 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.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds Informational [Page 15]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+20. 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 it
+
+
+
+Postel & 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 LH RFC 1149
+.ds RH 1 April 1990
+.ds CH IP Datagrams on Avian Carriers
+.hy 0
+.ad l
+.in 0
+Network Working Group D. Waitzman
+Request for Comments: 1149 BBN STC
+ 1 April 1990
+
+
+.ce
+A Standard for the Transmission of IP Datagrams on Avian Carriers
+
+.ti 0
+Status of this Memo
+
+.fi
+.in 3
+This memo describes an experimental method for the encapsulation of IP
+datagrams in avian carriers. This specification is primarily useful
+in Metropolitan Area Networks. This is an experimental, not recommended
+standard. Distribution of this memo is unlimited.
+
+.ti 0
+Overview and Rational
+
+Avian carriers can provide high delay, low throughput, and low
+altitude service. The connection topology is limited to a single
+point-to-point path for each carrier, used with standard carriers, but
+many carriers can be used without significant interference with each
+other, outside of early spring. This is because of the 3D ether space
+available to the carriers, in contrast to the 1D ether used by
+IEEE802.3. The carriers have an intrinsic collision avoidance system,
+which increases availability. Unlike some network technologies, such
+as packet radio, communication is not limited to line-of-sight
+distance. 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 0
+Frame Format
+
+The IP datagram is printed, on a small scroll of paper, in
+hexadecimal, 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. The
+bandwidth is limited to the leg length. The MTU is variable, and
+paradoxically, generally increases with increased carrier age. A
+typical MTU is 256 milligrams. Some datagram padding may be needed.
+
+Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.
+
+.ti 0
+Discussion
+
+Multiple types of service can be provided with a prioritized pecking
+order. An additional property is built-in worm detection and
+eradication. Because IP only guarantees best effort delivery, loss of
+a carrier can be tolerated. With time, the carriers are
+self-regenerating. While broadcasting is not specified, storms can
+cause data loss. There is persistent delivery retry, until the
+carrier drops. Audit trails are automatically generated, and can
+often be found on logs and cable trays.
+
+.ti 0
+Security Considerations
+
+.in 3
+Security is not generally a problem in normal operation, but special
+measures must be taken (such as data encryption) when avian carriers
+are used in a tactical environment.
+
+.ti 0
+Author's Address
+
+.nf
+David Waitzman
+BBN Systems and Technologies Corporation
+BBN Labs Division
+10 Moulton Street
+Cambridge, MA 02238
+
+Phone: (617) 873-4323
+
+EMail: dwaitzman@BBN.COM
+
+
+
+Postel & Reynolds Informational [Page 19]
+
+RFC 2223 Instructions to RFC Authors October 1997
+
+
+21. 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]
+