rfc2223.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   one site may not be identical to that copied from another site.

17.  Security Considerations

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

18.  References

   [1]  Postel, J., Editor, "Internet Official Protocol Standards", STD
        1, RFC 2200, June 1997.

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I Introduction to
        the F.Y.I. Notes", FYI 1, RFC 1150, March 1990.

   [5]  Postel, J., Li, T., and Y. Rekhter, "Best Current Practices",
        BCP 1, RFC 1818, August 1995.

   [6]  Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
        March 1992.










Postel & Reynolds            Informational                     [Page 14]

RFC 2223              Instructions to RFC Authors           October 1997


19.  Authors' Addresses

   Jon Postel
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Joyce K. Reynolds
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]































Postel & Reynolds            Informational                     [Page 15]

RFC 2223              Instructions to RFC Authors           October 1997


20.  Appendix - RFC "nroff macros"

   Generally, we use the very simplest nroff features.  We use the "ms"
   macros.  So, "nroff -ms input-file > output-file".  However, we could
   not get nroff to do the right thing about putting a form feed after
   the last visible line on a page and no extra line feeds before the
   first visible line of the next page.  We want:

        last visible line on page i
        ^L
        first visible line on page i+1

   So, we invented a hack to fix this.  We use a perl script called
   "fix.pl".  So the command to process the file becomes:

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

   The actual perl script is:


#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /local/bin/perl

# fix.pl  17-Nov-93  Craig Milo Rogers at USC/ISI
#
#       The style guide for RFCs calls for pages to be delimited by the
# sequence <last-non-blank-line><formfeed-line><first-non-blank-line>.
# Unfortunately, NROFF is reluctant to produce output that conforms to
# this convention.  This script fixes RFC-style documents by searching
# for the token "FORMFEED[Page", replacing "FORMFEED" with spaces,
# appending a formfeed line, and deleting white space up to the next
# non-white space character.
#
#       There is one difference between this script's output and that of
# the "fix.sh" and "pg" programs it replaces:  this script includes a
# newline after the formfeed after the last page in a file, whereas the
# earlier programs left a bare formfeed as the last character in the
# file.  To obtain bare formfeeds, uncomment the second substitution
# command below.  To strip the final formfeed, uncomment the third
# substitution command below.
#
#       This script is intended to run as a filter, as in:
#
# nroff -ms input-file | fix.pl > output-file
#
#       When porting this script, please observe the following points:
#
# 1)    ISI keeps perl in "/local/bin/perl";  your system may keep it



Postel & Reynolds            Informational                     [Page 16]

RFC 2223              Instructions to RFC Authors           October 1997


#       elsewhere.
# 2)    On systems with a CRLF end-of-line convention, the "\n"s below
#       may have to be replaced with "\r\n"s.

$* = 1;                                 # Enable multiline patterns.
undef $/;                               # Read whole files in a single
                                        # gulp.

while (<>) {                            # Read the entire input file.
    s/FORMFEED(\[Page\s+\d+\])\s+/        \1\n\f\n/g;
                                        # Rewrite the end-of-pages.
#    s/\f\n$/\f/;                       # Want bare formfeed at end?
#    s/\f\n$//;                         # Want no formfeed at end?
    print;                              # Print the resultant file.
}
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






   This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc-
   editor/fix.pl

   Now as to the nroff features we actually use, following is a sample
   memo, prepared in RFC style.
























Postel & Reynolds            Informational                     [Page 17]

RFC 2223              Instructions to RFC Authors           October 1997


.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Waitzman
.ds RF PUTFFHERE[Page %]
.ds CF
.ds LH RFC 1149
.ds RH 1 April 1990
.ds CH IP Datagrams on Avian Carriers
.hy 0
.ad l
.in 0
Network Working Group                                        D. Waitzman
Request for Comments: 1149                                       BBN STC
                                                            1 April 1990


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

.ti 0
Status of this Memo

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

.ti 0
Overview and Rational

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




Postel & Reynolds            Informational                     [Page 18]

RFC 2223              Instructions to RFC Authors           October 1997


.ti 0
Frame Format

The IP datagram is printed, on a small scroll of paper, in
hexadecimal, with each octet separated by whitestuff and blackstuff.
The scroll of paper is wrapped around one leg of the avian carrier.
A band of duct tape is used to secure the datagram's edges.  The
bandwidth is limited to the leg length.  The MTU is variable, and
paradoxically, generally increases with increased carrier age.  A
typical MTU is 256 milligrams.  Some datagram padding may be needed.

Upon receipt, the duct tape is removed and the paper copy of the
datagram is optically scanned into a electronically transmittable
form.

.ti 0
Discussion

Multiple types of service can be provided with a prioritized pecking
order.  An additional property is built-in worm detection and
eradication.  Because IP only guarantees best effort delivery, loss of
a carrier can be tolerated.  With time, the carriers are
self-regenerating.  While broadcasting is not specified, storms can
cause data loss.  There is persistent delivery retry, until the
carrier drops.  Audit trails are automatically generated, and can
often be found on logs and cable trays.

.ti 0
Security Considerations

.in 3
Security is not generally a problem in normal operation, but special
measures must be taken (such as data encryption) when avian carriers
are used in a tactical environment.

.ti 0
Author's Address

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

Phone: [phone]

EMail: [e-mail]



Postel & Reynolds            Informational                     [Page 19]

RFC 2223              Instructions to RFC Authors           October 1997


21.  Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
























Postel & Reynolds            Informational                     [Page 20]