RFC2223 - Instructions to RFCAuthors

Network Working Group J. Postel

Request for Comments: 2223 J. Reynolds

Obsoletes: 1543, 1111, 825 ISI

Category: Informational October 1997

InstrUCtions to RFCAuthors

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.

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. RFCIndex . . . . . . . . . . . . . . . . . . . . . . . . 14

17. Security Considerations . . . . . . . . . . . . . . . . . 14

18. References . . . . . . . . . . . . . . . . . . . . . . . . 14

19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15

20. Appendix - RFC"nroff macros" . . . . . . . . . . . . . . 16

21. Full Copyright Statement . . . . . . . . . . . . . . . . . 20

1. Introduction

This Request for Comments (RFC) provides information about the

preparation of RFCs, and certain policies relating to the publication

of RFCs.

The RFCseries 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 RFCEditor.

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

Most of the memos submitted to the RFCEditor 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 RFCmay 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 RFCpublication over

other possible systems (e.g., impress, interpress, oda) because of

the perceived wide spread availability of PostScript capable

printers.

However, many RFCusers 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 RFCEditor 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 RFCis

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

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 RFCEditor 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 RFCEditor 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 RFCthe

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 RFCEditor 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 RFCEditor

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 RFCis the primary version, the PostScript version must match the

text version. The RFCEditor 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 RFCEditor 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 RFCEditor agrees that it does), then the

PostScript version will be installed in the RFCrepositories and

announced to the community.

Due to various time pressures on the RFCEditorial staff, the time

elapsed between submission and publication can vary greatly. It is

always acceptable to query (ping) the RFCEditor about the status of

an RFCduring 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 RFCEditor attempts to ensure a consistent RFCstyle. To do this

the RFCEditor may choose to reformat the RFCsubmitted. 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 RFCEditor. The

RFCEditor may require or make minor changes in format or style and

will insert the actual RFCnumber.

Most of the RFCs are processed by the RFCEditor 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 RFChas been prepared by the author using

nroff, it is very helpful to let the RFCEditor 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 RFCEditor 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 RFCEditor first.

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 RFCEditor in

e-mail messages (or as online files). If you plan to submit a

document in PostScript please consult the RFCEditor first.

Note that since the ASCII text version of the RFCis the primary

version, the PostScript version must match the text version. The

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

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 RFCPublication. Indicated on

the third line on the right side.

Updates or Obsoletes

If this RFCUpdates or Obsoletes another RFC, this is indicated

as third line on the left side of the heading.

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 RFCseries 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 RFCnumber on the left (RFCNNNN), 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 RFCmust 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.

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

Also, see Section 11 for the full statement that must appear at the

end of the document.

7. Introduction Section

Each RFCshould have an Introduction section that (among other

things) explains the motivation for the RFCand (if appropriate)

describes the applicability of the protocol described.

Normally, this will be the "abstract" section from the Internet

Draft. If the RFCis not based on an I-D, other possibilities

are:

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.

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 RFCis 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 RFCis 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 RFCis 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 RFCmust be made clear.

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 RFCfor 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, RFC2119 [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 RFCmust 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, RFC2026 [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".

This document and translations of it may be copied and furnished

to others, and derivative works that comment on or otherwise

explain it or assist in its implementation may be prepared, copied,

published and distributed, in whole or in part, without

restriction of any kind, provided that the above copyright notice

and this paragraph are included on all such copies and derivative

works. However, this document itself may not be modified in any

way, such as by removing the copyright notice or references to the

Internet Society or other Internet organizations, except as needed

for the purpose of developing Internet standards in which case the

procedures for copyrights defined in the Internet Standards

process must be followed, or as required to translate it into

languages other than English.

The limited permissions granted above are perpetual and will not

be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on

an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

12. Relation to other RFCs

Sometimes an RFCadds information on a topic discussed in a previous

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

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 RFCthe communication

will be from the Secretary of the IESG to the RFCEditor. Generally,

the documents in question are Internet Drafts. The communication

usually cites the exact Internet Draft (by file name) in question.

The RFCEditor 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 RFCEditor separately (or as a "diff"), do

not send a new version of the document.

14. Contact

To contact the RFCEditor send an email message to:

"rfc-editor@isi.edu".

15. Distribution Lists

The RFCannouncements 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. RFCIndex

Several organizations maintain RFCIndex 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 RFCraises no security issues (however, see Section 9).

18. References

[1] Postel, J., Editor, "Internet Official Protocol Standards", STD

1, RFC2200, June 1997.

[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP

9, RFC2026, October 1996.

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC2119, March 1997.

[4] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to

the F.Y.I. Notes", FYI 1, RFC1150, March 1990.

[5] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices",

BCP 1, RFC1818, August 1995.

[6] Postel, J., Editor, "Introduction to the STD Notes", RFC1311,

March 1992.

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

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

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

# 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 RFCstyle.

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

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

.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

21. Full Copyright Statement

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