rfc1543.txt

RFC 的详细文档！

         "[e-mail]".

13.  Distribution Lists

   The RFC announcements are distributed via two mailing lists: the
   "IETF-Announce" list, and the "RFC-DIST" list.  You don't want to be
   on both lists.

   To join (or quit) the IETF-Announce list send a message to IETF-
   [e-mail].

   To join (or quit) the RFC-DIST list send a message to RFC-
   [e-mail].




Postel                                                         [Page 11]

RFC 1543              Instructions to RFC Authors           October 1993


14.  RFC Index

   Several organizations maintain RFC Index files, generally using the
   file name "rfc-index.txt".  The contents of such a file copied from
   one site may not be identical to that copied from another site.

15.  Security Considerations

   This RFC raises no security issues (however, see Section 6).

16.  References


   [1]  Postel, J., "Internet Official Protocol Standards", STD 1, RFC
        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: [phone]
   Fax:   [phone]
   EMail: [e-mail]

























Postel                                                         [Page 12]

RFC 1543              Instructions to RFC Authors           October 1993


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 line on page i
        ^L
        first visible line on page i+1

   So, we invented some hacks to fix this including a "sed" script
   called "fix.sh" and a "c" program we called "pg" (pg is called from
   fix).  So the command to process the file becomes:

        nroff -ms input-file | fix.sh > output-file

   Now as to the nroff features we actually use, I'll append a sample
   memo, prepared in RFC style.

   The sed script fix.sh is:

        sed -e 's/FORMFEED\[Page/        \[Page/' $* | pg -n5

The pg program is:

                     ~~~Beginning of pg program~~~

/* $Header$
 *
 *  Remove N lines following any line that contains a form feed (^L).
 *  (Why can't this be done with awk or sed?)
 *
 *  OPTION:
 *      -n#     Number of lines to delete following each ^L (0 default).
 * $Log$
 */
#include <stdio.h>
#define FORM_FEED       '\f'
#define OPTION          "n:N:"          /* for getopt() */

extern char *optarg;
extern int optind;

main(argc, argv)
int     argc;
char    *argv[];



Postel                                                         [Page 13]

RFC 1543              Instructions to RFC Authors           October 1993


{
  int   c,                              /* next input char */
        nlines = 0;                     /* lines to delete after ^L */
  void  print_and_delete();             /* print line starting with ^L,
                                           then delete N lines */

/* Process option (-nlines) */

  while ((c = getopt(argc, argv, OPTION)) != EOF)
    switch(c)
    {
      case 'n' :
      case 'N' :  nlines = atoi(optarg);
                  break;
    }
/* READ AND PROCESS CHARS */

  while ((c = getchar()) != EOF)
    if (c == FORM_FEED)
      print_and_delete(nlines);  /* remove N lines after this one */
    else
      putchar(c);                /* we write the form feed */
  exit(0);
}

/* Print rest of line, then delete next N lines. */

void print_and_delete(n)
int  n;                                 /* nbr of lines to delete */
{
  int   c,                              /* next input char */
        cntr = 0;                       /* count of deleted lines */

  while ((c = getchar()) != '\n')       /* finish current line */
    putchar(c);
  putchar('\n');                        /* write the last CR */
  putchar(FORM_FEED);

  for ( ; cntr < n; cntr++)
    while ((c = getchar()) != '\n')
      if (c == EOF)
        exit(0);                        /* exit on EOF */
  putchar(c);                           /* write that last CR */
}
                        ~~~End of pg program~~~






Postel                                                         [Page 14]

RFC 1543              Instructions to RFC Authors           October 1993


.pl 10.0i
.po 0
.ll 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 l
.in 0
Network Working Group                                        D. Waitzman
Request for Comments: 1149                                       BBN STC
                                                            1 April 1990


.ce
A Standard for the Transmission of IP Datagrams on Avian Carriers

.ti 0
Status of this Memo

.fi
.in 3
This memo describes an experimental method for the encapsulation of IP
datagrams in avian carriers.  This specification is primarily useful
in Metropolitan Area Networks.  This is an experimental, not recommended
standard.  Distribution of this memo is unlimited.

.ti 0
Overview and Rational

Avian carriers can provide high delay, low throughput, and low
altitude service.  The connection topology is limited to a single
point-to-point path for each carrier, used with standard carriers, but
many carriers can be used without significant interference with each
other, outside of early spring.  This is because of the 3D ether space
available to the carriers, in contrast to the 1D ether used by
IEEE802.3.  The carriers have an intrinsic collision avoidance system,
which increases availability.  Unlike some network technologies, such
as packet radio, communication is not limited to line-of-sight
distance.  Connection oriented service is available in some cities,
usually based upon a central hub topology.




Postel                                                         [Page 15]

RFC 1543              Instructions to RFC Authors           October 1993


.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: [phone]

EMail: [e-mail]



Postel                                                         [Page 16]