Network Working Group
`Request for Comments: 1543
`Obsoletes: RFCs 1111, 825
`Category:
`Informational
`
`J. Postel
`ISI
`October 1993
`
`Instructions
`
`to RFC Authors
`
`Status of this Memo
`
`community. This memo
`for the Internet
`information
`This memo provides
`does not specify an Internet
`standard of any kind. Distribution
`of
`this memo is unlimited.
`
`Table of Contents
`
`Introduction
`1.
`Editorial Policy
`2.
`.
`Format Rules
`3.
`3a. ASCII Format Rules
`Postscript
`Format Rules
`3b.
`. .
`. . .
`4. Header.
`First Page Heading
`4a.
`Running Header
`4b.
`Running Footer
`4c.
`Status Section .
`5.
`Introduction Section
`6.
`References Section .
`7.
`Security Considerations Section
`8.
`9. Author's Address Section
`to other RFCs .
`10. Relation
`Protocol Standards Process
`11.
`12. Contact
`Lists
`13. Distribution
`. .
`.
`14. RFC Index
`15. Security Considerations
`.
`.
`. . .
`16. References
`.
`17. Author's Address . .
`18. Appendix - RFC "nroff macros"
`
`1.
`
`Introduction
`
`1
`3
`4
`4
`5
`6
`6
`7
`7
`5
`8
`9
`10
`10
`10
`11
`11
`11
`12
`12
`12
`12
`13
`
`This Request for Comments (RFC) provides
`preparation of RFCs, and certain policies
`of RFCs.
`
`information about the
`relating
`to the publication
`
`The core
`The RFC series of notes covers a broad range of interests.
`topics are the Internet
`and the TCP/IP protocol
`suite. However, any
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 1]
`
`to computer communication may be acceptable at the
`related
`topic
`discretion
`of the RFC Editor.
`
`EX 1040 Page 1
`
`

`

`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.
`
`online by being stored as public access files,
`RFCs are distributed
`and a short message is sent to the distribution
`list
`indicating
`the
`availability
`of the memo.
`
`people and printed or
`are copied by the interested
`The online files
`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, WWW, or Mosaic.)
`
`RFCs have been traditionally
`in ASCII text.
`
`published and continue
`
`to be published
`
`secondary or
`file,
`While the primary RFCs is always an ASCII text
`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.
`
`over
`Postscript was chosen for the fancy form of RFC publication
`other possible
`systems (e.g.,
`impress,
`interpress,
`oda) because of
`the perceived wide spread availability
`of Postscript
`capable
`printers.
`
`However, many RFC users read the documents
`text oriented
`tools
`(e.g.,
`emacs, grep) to
`excerpts
`from RFCs are included
`in e-mail.
`yet practical with Postscript
`files.
`
`online and use various
`search them. Often, brief
`These practices
`are not
`
`than had been assumed
`producing systems are less standard
`Postscript
`and that several of the document production systems that claim to
`produce Postscript
`actually produce nonstandard
`results.
`
`a set of document
`to identify
`it may be necessary
`In the future,
`production systems authorized
`for use in production of Postscript
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 2]
`
`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.
`
`to the author some
`The result of the review may be to suggest
`improvements to the document before publication.
`
`Occasionally,
`
`it may become apparent
`
`that
`
`the topic of a proposed RFC
`
`EX 1040 Page 2
`
`

`

`the author
`is also the subject of an IETF Working Group, and that
`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.
`
`the submitted document is not
`In some cases it may be determined that
`appropriate material
`to be published as an RFC.
`
`in the document a
`to include
`In some cases it may be necessary
`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
`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.
`
`in
`
`track
`standards
`to become RFCs specifying
`Documents intended
`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
`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"),
`do not send a new version of the
`document.
`
`secondary versions of RFCs
`In some cases, authors prepare alternate
`in fancy format using Postscript.
`Since the ASCII text version of
`the RFC is the primary version,
`the Postscript
`version must match the
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 3]
`
`version
`if the Postscript
`The RFC Editor must decide
`text version.
`is "the same as" the ASCII version before the Postscript
`version can
`be published.
`
`the ASCII
`processes
`the RFC Editor first
`is that
`The effect of this
`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.
`
`the time
`staff
`time pressures on the RFC Editorial
`Due to various
`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
`
`EX 1040 Page 3
`
`

`

`rules are
`the following
`constraints,
`To meet the distribution
`established
`for the two allowed formats for RFCs: ASCII and
`Postscript.
`
`To do this
`to ensure a consistent RFC style.
`The RFC Editor attempts
`It
`is much
`the RFC Editor may choose to reformat
`the RFC submitted.
`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.
`RFC Editor may require minor changes in format or style and will
`insert
`the actual RFC number.
`
`The
`
`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
`submitted.
`
`is
`
`3a. ASCII Format Rules
`
`The character
`
`codes are ASCII.
`
`Each page must be limited
`line by itself.
`
`to 58 lines
`
`followed by a form feed on a
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 4]
`
`Each line must be limited
`return and line feed.
`
`to 72 characters
`
`followed by carriage
`
`No overstriking
`
`(or underlining)
`
`is allowed.
`
`include any headers,
`These "height" and "width" constraints
`footers,
`page numbers, or left
`side
`indenting.
`
`Do not fill
`margin.
`
`the text with extra spaces to provide a straight
`
`right
`
`Do not do hyphenation of words at the right margin.
`
`If such notes are necessary, put them at
`Do not use footnotes.
`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.
`
`the number of pages in a document and the page numbers
`Note that
`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.
`
`in e-mail
`to the RFC Editor
`RFCs in ASCII Format may be submitted
`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.
`
`EX 1040 Page 4
`
`

`

`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
`a line spacing of 12 points.
`
`than 10 points with
`
`Footnotes and graph notations no smaller
`spacing of 9.6 points.
`
`than 8 points with a line
`
`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
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 5]
`
`memory requirements.
`
`commands should not be used:
`The following Postscript
`copypage, grestoreall,
`initmatrix,
`initgraphics,
`erasepage,
`initclip,
`banddevice,
`framedevice, nulldevice and renderbands.
`
`the number of pages in a document and the page numbers
`Note that
`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.
`
`rules are likely
`These Postscript
`experience
`is gained.
`
`to changed and expanded as
`
`in
`to the RFC Editor
`Format may be submitted
`RFCs in Postscript
`e-mail messages (or as online files).
`If you plan to submit a
`document in Postscript
`please consult
`the RFC Editor first.
`
`Note that since the ASCII text version of the RFC is the primary
`version,
`the Postscript
`version must match the text version.
`The
`RFC Editor must decide
`if the Postscript
`version
`is "the same as"
`the ASCII version before the Postscript
`version can be published.
`
`4. Headers and Footers
`
`There is the first
`footers.
`
`4a. First Page
`
`page heading,
`
`the running headers, and the running
`
`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
`
`EX 1040 Page 5
`
`

`

`This appears on the first
`series.
`of the heading.
`
`line on the left hand side
`
`Request for Comments: nnnn
`
`for comments and specifies
`this as a request
`Identifies
`Indicated on the second line on the left
`side.
`number.
`actual number is filled
`in at the last moment before
`publication
`by the RFC Editor.
`
`the
`The
`
`Postel
`
`RFC 1543
`
`Author
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 6]
`
`and last name only)
`initial
`The author's name (first
`on the first
`line on the right side of the heading.
`
`indicated
`
`Organization
`
`The author's organization,
`right side.
`
`indicated on the second line on the
`
`Date
`
`This is the Month and Year of the RFC Publication.
`the third
`line on the right side.
`
`Indicated on
`
`Updates or Obsoletes
`
`If this RFC Updates or Obsoletes another RFC, this
`as third
`line on the left
`side of the heading.
`
`is indicated
`
`Category
`
`The category of this RFC, one of: Standards Track,
`Informational,
`or Experimental.
`This is indicated on the third
`(if
`there
`is no Updates or Obsoletes
`indication)
`or fourth
`line
`of the left
`side.
`
`Title
`
`The title
`
`appears, centered, below the rest of the heading.
`
`If there are multiple authors and if the multiple authors are from
`multiple organizations
`the right side heading may have additional
`lines
`to accommodate them and to associate
`the authors with the
`organizations
`properly.
`
`4b. Running Headers
`
`(on page 2 and all subsequent
`The running header in one line
`pages) has the RFC number on the left
`(RFC NNNN), the (possibly a
`shortened form) title
`centered,
`and the date (Month Year) on the
`right.
`
`4c. Running Footers
`
`(on all pages) has the author's
`in one line
`The running footer
`last name on the left and the page number on the right
`([Page N]).
`
`EX 1040 Page 6
`
`

`

`Postel
`
`RFC 1543
`
`5. Status Section
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 7]
`
`page the "Status of this Memo"
`first
`Each RFC must include on its
`section which contains a paragraph describing
`the type of the RFC.
`
`The content of this section will be one of the three
`statements.
`
`following
`
`Standards Track
`
`for
`track protocol
`standards
`an Internet
`"This document specifies
`and suggestions
`the Internet
`community, and requests discussion
`for
`improvements. Please refer
`to the current edition of the
`"Internet Official Protocol Standards"
`(STD 1) for the
`standardization
`state and status of this protocol.
`Distribution
`of this memo is unlimited."
`
`Experimental
`
`"This memo defines an Experimental Protocol for the Internet
`community. This memo does not specify an Internet
`standard of any
`kind. Discussion and suggestions
`for improvement are requested.
`Distribution
`of this memo is unlimited."
`
`Informational
`
`community. This
`for the Internet
`information
`"This memo provides
`memo does not specify an Internet
`standard of any kind.
`Distribution
`of this memo is unlimited."
`
`6.
`
`Introduction Section
`
`Each RFC should have an Introduction
`(among other
`that
`section
`things) explains
`the motivation
`for the RFC and (if appropriate)
`describes
`the applicability
`of the protocol described.
`
`Some example paragraphs are:
`
`Protocol
`
`service,
`to provide the bla-bla
`is intended
`This protocol
`and be used between clients
`and servers on host computers.
`Typically
`the clients
`are on workstation hosts and the
`servers on mainframe hosts.
`
`or
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 8]
`
`EX 1040 Page 7
`
`

`

`service,
`to provide the bla-bla
`is intended
`This protocol
`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
`
`to members of the Internet
`This RFC is being distributed
`their
`reactions
`to the
`community in order to solicit
`proposals contained
`in it. While the issues discussed may
`not be directly
`relevant
`to the research problems of the
`Internet,
`they may be interesting
`to a number of researchers
`and implementers.
`
`Status Report
`
`In response to the need for maintenance of current
`information about the status and progress of various
`projects
`in the Internet
`community, this RFC is issued for
`the benefit of community members. The information contained
`in this document is accurate as of the date of publication,
`but is subject
`to change. Subsequent RFCs will
`reflect
`such
`changes.
`
`These paragraphs need not be followed word for word, but the
`general
`intent of the RFC must be made clear.
`
`7. References Section
`
`to other documents, and these are
`Nearly all RFCs contain citations
`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
`for
`reference
`section of this RFC for an example. Please note that
`protocols
`that have been assigned STD numbers, the STD number must be
`included
`in the reference.
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 9]
`
`8. Security Considerations Section
`
`All RFCs must contain a section near the end of the document that
`discusses
`the security
`considerations
`of the protocol or procedures
`that are the main topic of the RFC.
`
`9. Author's Address Section
`
`Each RFC must have at the very end a section giving
`
`the author's
`
`EX 1040 Page 8
`
`

`

`address,
`(optional:
`
`the telephone number,
`the name and postal address,
`including
`a FAX number) and the Internet
`e-mail address.
`
`10. Relation
`
`to other RFCs
`
`in a previous
`Sometimes an RFC adds information on a topic discussed
`RFC or completely replaces an earlier RFC. There are two terms used
`for these cases respectively, UPDATES and OBSOLETES. A document that
`obsoletes an earlier
`document can stand on its own. A document that
`merely updates an earlier
`document cannot stand on its own; it
`is
`something that must be added to or inserted
`into
`the previously
`existing document, and has limited usefulness
`independently.
`The
`terms SUPERSEDES and REPLACES are no longer used.
`
`UPDATES
`
`from a new item that cannot be used
`To be used as a reference
`alone (i.e.,
`one that supplements a previous document), to refer
`to the previous document. The newer publication
`is a part
`that
`an
`will supplement or be added on to the existing document; e.g.,
`addendum, or separate,
`extra
`information
`that
`is to be added to
`the original
`document.
`
`OBSOLETES
`
`is replaced by
`document that
`to an earlier
`To be used to refer
`this document. This document contains either
`revised
`information,
`or else all of the same information plus some new information,
`however extensive or brief
`that new information
`is;
`i.e.,
`this
`document can be used alone, without reference
`to the older
`document.
`
`For example:
`
`On the Assigned Numbers RFCs the term OBSOLETES should be used
`since the new document actually
`incorporate new information
`(however brief)
`into the text of existing
`information and is
`more up-to-date
`than the older document, and hence, replaces
`and makes it OBSOLETE.
`
`it
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 10]
`
`of RFCs or the RFC-Index (but not on the RFCs themselves)
`In lists
`the following may be used with early documents to point to later
`documents.
`
`OBSOLETED-BY
`
`To be used to refer
`older document.
`
`UPDATED-BY
`
`to the newer document(s) that
`
`replaces
`
`the
`
`to the newer section(s) which are to be added
`To be used to refer
`to the existing,
`still
`used, document.
`
`11. Protocol Standards Process
`
`(STD 1) memo
`See the current "Internet Official Protocol Standards"
`for the definitive
`statement on protocol
`standards and their
`
`EX 1040 Page 9
`
`

`

`publication
`
`[1].
`
`is that when the IESG completes work on a
`procedure
`The established
`is to become a standards
`track RFC the communication
`document that
`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.
`to
`The RFC Editor must assume that only that
`file
`is to be processed
`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"),
`not send a new version of the document.
`
`do
`
`12. Contact
`
`To contact
`
`the RFC Editor send an email message to
`
`"RFC-Editor@ISI.EDU".
`
`13. Distribution
`
`Lists
`
`the
`lists:
`via two mailing
`The RFC announcements are distributed
`"IETF-Announce" list,
`and the "RFC-DIST" list.
`You don't want to be
`on both lists.
`
`the IETF-Announce list
`To Join (or quit)
`Request@cnri.reston.va.us.
`
`send a message to IETF(cid:173)
`
`the RFC-DIST list
`(or quit)
`To join
`Request@NIC.DDN.MIL.
`
`send a message to RFC(cid:173)
`
`Postel
`
`RFC 1543
`
`14. RFC Index
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 11]
`
`generally using the
`Several organizations maintain RFC Index files,
`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.
`
`15. Security Considerations
`
`This RFC raises no security
`
`issues
`
`(however, see Section 6).
`
`16. References
`
`"Internet Official Protocol Standards", STD 1, RFC
`J.,
`[1] Postel,
`1540, Internet Architecture Board, October 1993.
`
`17. Author's Address
`
`Jon Postel
`USC/Information Sciences Institute
`4676 Admiralty Way
`Marina del Rey, CA 90292
`
`Phone: 310-822-1511
`Fax:
`310-823-6714
`EMail: Postel@ISI.EDU
`
`EX 1040 Page 10
`
`

`

`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 12]
`
`18. 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
`AL
`first
`
`visible
`
`line on page i
`
`line on page i+l
`
`including a "sed" script
`this
`So, we invented some hacks to fix
`called "fix.sh"
`and a "c" program we called "pg" (pg is called
`fix).
`So the command to process
`the file becomes:
`I fix.sh>
`
`nroff
`
`-ms input-file
`
`output-file
`
`from
`
`Now as to the nroff features we actually use, I'll
`memo, prepared
`in RFC style.
`
`append a sample
`
`The sed script
`
`fix.sh
`
`is:
`
`sed -e
`
`'s/FORMFEED\[Page/
`
`\[Page/'
`
`$* I pg -ns
`
`The pg program is:
`
`~~~Beginning of pg program~~~
`
`/* $Header$
`*
`that contains a form feed (AL).
`following any line
`* Remove N lines
`*
`(Why can't
`this be done with awk or sed?)
`*
`* OPTION:
`*
`-n#
`
`Number of lines
`
`to delete
`
`following each AL (0 default).
`
`EX 1040 Page 11
`
`

`

`'\f'
`lln:N: II
`
`/* for getopt() */
`
`* $Log$
`*/
`#include <stdio.h>
`#define FORM_FEED
`#define OPTION
`
`extern char *optarg;
`extern
`int optind;
`
`main(argc, argv)
`int
`argc;
`char
`*argv[];
`
`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 13]
`
`{
`
`int
`
`c,
`nlines = 0;
`void print_and_delete();
`
`/* Process option (-nlines)
`
`*/
`
`/* next input char*/
`/* lines
`to delete after AL*/
`/* print
`line starting with AL,
`then delete N lines*/
`
`argv, OPTION)) != EOF)
`
`while ((c = getopt(argc,
`switch(c)
`{
`
`case
`case
`
`'n'
`'N'
`
`nlines = atoi(optarg);
`break;
`
`}
`/* READ AND PROCESS CHARS*/
`
`!= EOF)
`while ((c = getchar())
`if (c == FORM_FEED)
`print_and_delete(nlines);
`else
`putchar(c);
`exit(0);
`
`/* remove N lines after
`
`this one*/
`
`/* we write
`
`the form feed*/
`
`}
`
`/* Print
`
`rest of line,
`
`then delete next N lines. */
`
`void print_and_delete(n)
`int
`n;
`{
`
`int
`
`c,
`cntr = 0;
`
`/* nbr of lines
`
`to delete */
`
`/* next input char*/
`/* count of deleted
`
`lines */
`
`while ((c = getchar())
`putchar(c);
`putchar('\n');
`putchar(FORM_FEED);
`
`!= I \n O)
`
`/* finish
`
`current
`
`line*/
`
`/* write
`
`the last CR*/
`
`cntr < n; cntr++)
`for (;
`while ((c = getchar())
`(c == EOF)
`if
`exit(0);
`putchar(c);
`
`!= , \n,)
`
`/* exit on EOF */
`that
`last CR*/
`/* write
`
`~~~End of pg program~~~
`
`}
`
`EX 1040 Page 12
`
`

`

`Postel
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 14]
`
`.pl 10.0i
`.po 0
`.11 7.2i
`.lt 7.2i
`.nr LL 7.2i
`.nr LT 7.2i
`.ds LF Waitzman
`.ds RF FORMFEED[Page %]
`.ds CF
`.ds LH RFC 1149
`.ds RH 1 April 1990
`.ds CH IP Datagrams on Avian Carriers
`.hy 0
`.ad 1
`.in 0
`Network Working Group
`Request for Comments: 1149
`
`D. Waitzman
`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
`of IP
`an experimental method for the encapsulation
`This memo describes
`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
`
`and low
`low throughput,
`can provide high delay,
`Avian carriers
`to a single
`altitude
`service.
`The connection
`topology
`is limited
`but
`point-to-point
`path for each carrier,
`used with standard carriers,
`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 lD 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
`
`RFC 1543
`
`Instructions
`
`to RFC Authors
`
`October 1993
`
`[Page 15]
`
`EX 1040 Page 13
`
`

`

`.ti 0
`Frame Format
`
`in
`The IP datagram is printed, on a small scroll of paper,
`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.
`
`the duct tape is removed and the paper copy of the
`Upon receipt,
`datagram is optically
`scanned into a electronically
`transmittable
`form .
`
`. ti 0
`Discussion
`
`pecking
`types of service can be provided with a prioritized
`Multiple
`order. An additional
`property
`is built-in worm detection
`and
`eradication.
`Because IP only guarantees best effort delivery,
`a carrier
`can be tolerated. With time,
`the carriers
`are
`storms can
`self-regenerating.
`While broadcasting
`is not specified,
`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 .
`
`loss of
`
`. ti 0
`Security Considerations
`
`.in 3
`but special
`a problem in normal operation,
`is not generally
`Security
`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
`
`[Page 16]
`
`EX 1040 Page 14
`
`