RFC 2223

Instructions to RFC Authors

📅 published October 1997, from ietf

Instructions to RFC Authors 📝✨

Bestie, this is the RFC that tells you how to write an RFC! 💅 It's written by J. Postel and J. Reynolds at ISI 🦋 and it's Informational (so it doesn't set any Internet standard, it just gives info) 🌸. It's dated October 1997 🎀.

It obsoletes RFC 1543, RFC 1111 and RFC 825 🧚, so those older versions are out of date now. It doesn't update anything else. Lowkey a clean slate! ✨

Part 1 of 4 🫶 More parts are coming, so stay tuned!

Status of this Memo 🌈

Okay so this memo is just here to share information with the Internet community 💜. It is not a standard of any kind, so don't go treating it like one 🙈. Distribution is unlimited, so you can pass it around as much as you want 🔥.

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

1. Introduction 🦋

Okay, so this RFC (Request for Comments) gives you the scoop on how to prepare RFCs, plus some of the publication rules that go with them 💅.

The RFC series covers a lot of topics 🌈. The big core ones are the Internet and the TCP/IP protocol suite, but honestly, any computer communication topic might be accepted if the RFC Editor says yes 🧚.

Anyone can submit a memo to become an RFC 🫶. A big chunk of them come from the Internet Engineering Task Force (IETF) ✨. IETF working groups (WGs) develop their working memos, which are called Internet Drafts (or I-Ds), until they feel ready to publish 🌸. Then the Internet Engineering Steering Group (IESG) reviews them and, if they approve, sends them to the RFC Editor 👑.

Memos from independent sources usually get looked over by the IESG first 🔥. They're checking whether the memo relates to any work already happening in the IETF Working Groups 💜.

RFCs are distributed online as public access files 💖. A short message goes out to the distribution list to say the memo is available 📬.

People copy the online files and print or display them on their own equipment 🖨️. That's a lot of different hardware, so the online files have to work with a wide variety of printing and display equipment 🎀. (RFCs can also be sent by e-mail in reply to an e-mail query, or found with searching tools like Gopher, Wais, or the World Wide Web (WWW) 🌐.

RFCs have traditionally been published in ASCII text, and they still are 💜.

The primary version of an RFC is always an ASCII text file ✨. Secondary or alternative versions may also be provided in PostScript 🦄. The reason is that PostScript lets you include diagrams, drawings, and that kind of thing 🎨. On paper (so far, anyway), PostScript documents look more appealing and are easier to read 😍.

PostScript was picked for the fancy version over other options (like impress, interpress, and oda) because PostScript-capable printers were perceived to be widely available 🖨️✨.

Here's the catch though 🙈. Lots of RFC users read the documents online and use text tools (like emacs and grep) to search them. People also often paste brief excerpts into e-mail. None of that is practical yet with PostScript files 😭.

Also, PostScript producing systems aren't as standard as they should be 💀. Several document production systems that claim to produce PostScript actually produce nonstandard results 🥴.

Down the road, it may be necessary to name a set of document production systems that are authorized to produce PostScript RFCs, based on how reasonable their output files are 📋.

2. Editorial Policy 💅

Documents proposed as RFCs get reviewed by the RFC Editor, and possibly by other reviewers the RFC Editor picks 🔍.

The review might suggest some improvements to the document before it gets published 🌷.

Sometimes it becomes clear that a proposed RFC's topic is also being worked on by an IETF Working Group 👯. In that case, the author could coordinate with the group, which helps everyone 🫶. Usually, this means a revised memo becomes a working group Internet Draft and eventually comes out of the IETF process as a recommendation from the IESG to the RFC Editor 🚀.

In some cases, the submitted document turns out not to be appropriate for publication as an RFC 🙅‍♀️.

Sometimes the document needs a statement, based on the reviews, about the ideas in it 📣. This can happen when the document suggests ideas that are relevant but inappropriate or unsafe, among other situations ⚠️.

The RFC Editor can make minor changes to a document, especially to style and format, and sometimes to the text too ✏️. Sometimes the RFC Editor takes on bigger changes, especially when the format rules (see below) haven't been followed 🧐. More often, though, the memo gets sent back to the author for more work 🔁.

Documents meant to become standards track RFCs must be approved by the IESG before they go to the RFC Editor 👑. The usual process is that once the IESG finishes work on a document that's going to be a standards track RFC, the Secretary of the IESG contacts the RFC Editor 📨. These documents are generally Internet Drafts 💌. The message usually names the exact Internet Draft (by file name) 🗂️. The RFC Editor has to assume that only that file should be processed into the RFC 🔒. If the authors have small corrections to the text, they should send them to the RFC Editor separately (or as a "diff"). Authors should not send a new version of the document 🙅‍♀️.

Sometimes authors make alternate secondary versions of RFCs in fancy PostScript format 🎀. Since the ASCII text version is the primary one, the PostScript version has to match the text version 💯. The RFC Editor has to decide whether the PostScript version is "the same as" the ASCII version before it can be published 🧐.

So the RFC Editor processes the ASCII version through to publication as an RFC first 🥇. If the author then wants to submit a PostScript version that matches the ASCII version (and the RFC Editor agrees that it does), that PostScript version gets installed in the RFC repositories and announced to the community 📢.

Because the RFC Editorial staff are under a lot of time pressure, the time between submission and publication can vary a lot 😵‍💫. It's always fine to check in (ping) with the RFC Editor about an RFC's status during this time, just not more than once a week ⏰. The two weeks before an IETF meeting are generally super busy, so RFCs submitted shortly before a meeting are most likely to get published after it 🗓️✨.

More to come, bestie! 💜🫶

3. Format Rules ✨

Okay so, to meet the distribution constraints, there are rules for the two allowed formats for RFCs: ASCII and PostScript 💅 The format police are seriously strict about this, bestie.

The RFC Editor works hard to keep a consistent RFC style 🎀 They may reformat your RFC to get there, and it's way easier on everyone if your submission already matches the style of the most recent RFCs. So please 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 they'll insert the actual RFC number 🦋

Most RFCs get processed by the RFC Editor with the unix "nroff" program, using a very simple set of formatting commands (or "requests") from the "ms" macro package (see the Appendix) 💜 If you prepared your memo with nroff, it's super helpful to let the RFC Editor know when you submit it 🫶

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. Yes, the indenting counts too 😭

Do not fill the text with extra spaces to provide a straight right margin. No faking a justified look, babe 💅

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. So cross references by section number are usually way 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 💖

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 between the ASCII and the PostScript versions. So again, cross references by section number are easier to keep consistent than cross references by page number 💜

These PostScript rules are likely to be 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 ✨

Here's the big one: 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. No shortcuts, periodt 👑

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 🦋 It goes on the first line, on the left hand side of the heading.
  • Request for Comments: nnnn: this identifies the document as a request for comments and specifies the number. It goes on the second line, on the left side. The RFC Editor fills in the actual number at the last moment before publication 🌸
  • Author: the author's name (first initial and last name only), on the first line, on the right side of the heading 💅
  • Organization: the author's organization, on the second line, on the right side 🏢
  • Date: the Month and Year of the RFC publication, on the third line, on the right side 📅
  • Updates or Obsoletes: if this RFC Updates or Obsoletes another RFC, that gets indicated on the 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 🏷️ It goes on the third line on the left side if there's no Updates or Obsoletes indication, or on the fourth line if there is.
  • Other Numbers: other numbers in the RFC series include the subseries of FYI (For Your Information) [4], BCP (Best Current Practice) [5], and STD (Standard) [6]. These go on the left side 🧩
  • Title: the title appears centered, below the rest of the heading. Periods or "dots" in titles are not allowed, so no dots, no drama 🚫

If there are multiple authors, and the multiple authors are from multiple organizations, the right side heading may have additional lines to fit them all in and to associate each author with the right organization 👯‍♀️

4b. Running Headers

The running header is one line (on page 2 and all subsequent pages). It has the RFC number on the left (RFC NNNN), the title (possibly shortened) centered, and the date (Month Year) on the right 🧁

4c. Running Footers

The running footer is one line (on all pages). It has the author's last name on the left, the 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. Pick the one that matches your category, bestie 💖

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

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:

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 don't need to be followed word for word, but the general intent of the RFC must 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 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. This one is not optional, bestie, so don't skip it 🚨

10. Author's Address Section ✨

Okay bestie, every RFC has to end with an author's address section 🫶 It needs the name, the postal address, the phone number, (optional: a FAX number 📠 very 90s, I love it), and the internet email address 💌

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". Here it is, complete and exactly as written:

"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 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 info on a topic from a previous RFC, or it completely replaces an earlier one 🔄 There are two terms for these cases: 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 has to be added to or inserted into the existing document, so it's only of limited use by itself. The terms Supercedes and Replaces are no longer used.

Updates

This is 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

This is 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

This is used to refer to the newer document(s) that replaces the older document.

Updated-by

This is used to refer to the newer section(s) which are to be added to the existing, still used, document.

13. Protocol Standards Process 📜

Check out the current "Internet Official Protocol Standards" (STD 1) memo for the definitive statement on protocol standards and their publication [1] 🧐

The established procedure goes like this: when the IESG finishes work on a document that's going to become a standards track RFC, the Secretary of the IESG talks to the RFC Editor. Usually the documents in question are Internet Drafts, and the message cites the exact Internet Draft (by file name). The RFC Editor has to assume that only that file is to be processed to become the RFC. If the authors have small corrections to the text, they should send them 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

15. Distribution Lists 📬

RFC announcements go out through 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, usually using the file name rfc-index.txt. The contents of one of these files copied from one site may not be identical to the one copied from another site. Different copies, different vibes 🌈

17. Security Considerations 🔐

This RFC raises no security issues (however, see Section 9). 😤 Read Section 9 though, it's the real drama 🎭

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.

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 the layout below:

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

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

.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, bestie. ✨ There's also built-in worm detection and eradication, so that's a whole vibe 🐛💅. IP only promises best effort delivery, which means losing a carrier is totally tolerable 🦋. With time, the carriers are self-regenerating 🌱. Broadcasting is not specified, but storms can cause data loss 💀. Delivery is retried persistently until the carrier drops 🫶. Audit trails are generated automatically and can often be found on logs and cable trays 📜.

Security Considerations ✨

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 🔐💀. Don't skip this one, bestie!

Author's Address 🎀

David Waitzman
BBN Systems and Technologies Corporation
BBN Labs Division
10 Moulton Street
Cambridge, MA 02238

Phone: (617) 873-4323

EMail: dwaitzman@BBN.COM

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

📦 where this page comes from