doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc1100.txt b/doc/rfc/rfc1100.txt
new file mode 100644
index 0000000..5bc712e
--- /dev/null
+++ b/doc/rfc/rfc1100.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                          Internet Activities Board
+Request for Comments: 1100                                    April 1989
+Obsoletes: RFC 1083
+
+
+
+                    IAB OFFICIAL PROTOCOL STANDARDS
+
+
+Status of this Memo
+
+   This memo describes the state of standardization of protocols used in
+   the Internet as determined by the Internet Activities Board (IAB).
+   An overview of the standards procedures is presented first, followed
+   by discussions of the standardization process and the RFC document
+   series, then the explanation of the terms is presented, the lists of
+   protocols in each stage of standardization follows, and finally
+   pointers to references and contacts for further information.
+
+   This memo is issued quarterly, please be sure the copy you are
+   reading is dated within the last three months.  Current copies may be
+   obtained from the Network Information Center or from the Internet
+   Assigned Numbers Authority (see the contact information at the end of
+   this memo).  Do not use this memo after 31-July-89.
+
+   Distribution of this memo is unlimited.
+
+1.  Overview of Standards Procedures
+
+   The Internet Activities Board maintains a list of documents that
+   define standards for the Internet protocol suite.  It provides these
+   standards with the goal of co-ordinating the evolution of the
+   Internet protocols; this co-ordination has become quite important as
+   the Internet protocols are increasingly in general commercial use.
+
+   Protocol standards may be proposed by anyone in the Internet
+   community, by writing and submitting an RFC.  In general, any
+   proposed protocol will be reviewed or developed in the context of
+   some Task Force of the IAB, or some working group within that Task
+   Force.  The IAB will assign a proposed protocol to a working group if
+   official delegation is necessary.
+
+   The recommendation of the working group or task force is given major
+   consideration in the decision by the IAB to assign a state and status
+   to the protocol.  The general policy is not to designate a protocol
+   as an official standard until there is implementation experience with
+   it.
+
+
+
+
+Internet Activities Board                                       [Page 1]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+   In cases where there is uncertainty as to the proper decision
+   concerning a protocol, the IAB may convene a special review committee
+   consisting of interested parties from the working group and members
+   of the IAB itself, with the purpose of recommending some explicit
+   action to the IAB.
+
+   It is possible to proceed with widespread implementation of a
+   standard without the approval of the IAB.  For example, some vendor
+   standards have become very important to the Internet community even
+   though they have not been proposed or reviewed by the IAB.  However,
+   the IAB strongly recommends that the IAB standards process be used in
+   the evolution of the protocol suite to maximize interoperability (and
+   to prevent incompatible protocol requirements from arising).  The IAB
+   reserves the use of the term "standard" in any RFC to only those
+   protocols which the IAB has approved.
+
+2.  The Standardization Process
+
+   Anyone can invent a protocol, document it, implement it, test it, and
+   so on.  The IAB believes that it is very useful to document a
+   protocol at an early stage to promote suggestions from others
+   interested in the functionality the of protocol and from those
+   interested in protocol design.  Once a protocol is implemented and
+   tested it is useful to report the results.  The RFC document series
+   is the preferred place for publishing these protocol documents and
+   testing results.
+
+   The IAB encourages the documenting of every protocol developed in the
+   Internet (that is, the publication of the protocol specification as
+   an RFC), even if it is never intended that the protocol become an
+   Internet standard.  A protocol that is not intended to become a
+   standard is called "experimental".
+
+   Protocols that are intended to become standards are first designated
+   as "proposed" protocols.  It is expected that while in this state the
+   protocol will be implemented and tested by several groups.  It is
+   likely that an improved version of the protocol will result from this
+   activity.
+
+   Once a proposed protocol has become stable and has a sponsor (an
+   individual willing to speak for the protocol to the IAB) it may
+   advance to the "draft standard" state.  In this state, it should be
+   reviewed by the entire Internet community.  This draft standard state
+   is essentially a warning to the community that unless an objection is
+   raised or a flaw is found this protocol will become a "standard".
+
+   Once a protocol has been a draft standard for a sufficient time
+   (usually 6 months) without serious objections the IAB may act to
+
+
+
+Internet Activities Board                                       [Page 2]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+   declare the protocol an official Internet standard.
+
+   Some protocols have been superseded by better protocols or are
+   otherwise unused.  Such protocols are designated "historic".
+
+   In addition to a state (like proposed or standard) a protocol is also
+   assigned a status.  A protocol can be required, meaning that all
+   systems in the Internet must implement it.  For example, the Internet
+   Protocol (IP) is required.  A protocol may be recommended, meaning
+   that systems should implement this protocol.  A protocol may be
+   elective, meaning that systems may implement this protocol; that is,
+   if (and only if) the functionality of this protocol is needed or
+   useful for a system it must use this protocol to provide the
+   functionality.  A protocol may be termed not recommended if it is not
+   intended to be generally implemented; for example, experimental or
+   historic protocols.
+
+   Few protocols are required to be implemented in all systems.  This is
+   because there is such a variety of possible systems; for example,
+   gateways, terminal servers, workstations, multi-user hosts.  It is
+   not necessary for a gateway to implement TCP and the protocols that
+   use TCP (though it may be useful).  It is expected that general
+   purpose hosts will implement at least IP (including ICMP), TCP and
+   UDP, Telnet, FTP, SMTP, Mail, and the Domain Name System (DNS).
+
+3.  The Request for Comments Documents
+
+   The documents called Request for Comments (or RFCs) are the working
+   notes of the Internet research and development community.  A document
+   in this series may be on essentially any topic related to computer
+   communication, and may be anything from a meeting report to the
+   specification of a standard.  All standards are published as RFCs,
+   but not all RFCs specify standards.
+
+   Anyone can submit a document for publication as an RFC.  Submissions
+   must be made via electronic mail to the RFC Editor (see the contact
+   information at the end of this memo).
+
+   While RFCs are not refereed publications, they do receive technical
+   review form the task forces, individual technical experts, or the RFC
+   Editor, as appropriate.
+
+   Once a document is assigned an RFC number and published, that RFC is
+   never revised or re-issued with the same number.  There is never a
+   question of having the most recent version of a particular RFC.
+   However, a protocol (such as File Transfer Protocol (FTP)) may be
+   improved and re-documented many times in several different RFCs.  It
+   is important to verify that you have the most recent RFC on a
+
+
+
+Internet Activities Board                                       [Page 3]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+   particular protocol.  This "IAB Official Protocol Standards" memo is
+   the reference for determining the correct RFC to refer to for the
+   current specification of each protocol.
+
+   The RFCs are available from the Network Information Center at SRI
+   International.  For more information about obtaining RFCs see the
+   contact information at the end of this memo.
+
+4.  Other Reference Documents
+
+   There are four other reference documents of interest in checking the
+   current status of protocol specifications and standardization.  These
+   are the Assigned Numbers, the Official Protocols, the Gateway
+   Requirements, and the Host Requirements.  Note that these documents
+   are revised and updated at different times; in case of differences
+   between these documents, the most recent must prevail.
+
+   Also one should be aware of the MIL-STD publications on IP, TCP,
+   Telnet, FTP, and SMTP.  These are described in section 4.5.
+
+4.1.  Assigned Numbers
+
+   This document lists the assigned values of the parameters used in the
+   various protocols.  For example, IP protocol codes, TCP port numbers,
+   Telnet Option Codes, ARP hardware types, and Terminal Type names.
+   Assigned Numbers was most recently issued as RFC-1010.
+
+   Another document, Internet Numbers, lists the assigned IP network
+   numbers, and the autonomous system numbers.  Internet Numbers was
+   most recently issued as RFC-1062.
+
+4.2.  Official Protocols
+
+   This document list the protocols and describes any known problems and
+   ongoing experiments.  Official Protocols was recently issued as RFC-
+   1011.
+
+4.3.  Gateway Requirements
+
+   This document reviews the specifications that apply to gateways and
+   supplies guidance and clarification for any ambiguities. Gateway
+   Requirement was recently issued as RFC-1009.
+
+4.4.  Host Requirements
+
+   This document reviews the specifications that apply to hosts and
+   supplies guidance and clarification for any ambiguities. Host
+   Requirements is in preparation and will be issued soon.
+
+
+
+Internet Activities Board                                       [Page 4]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+4.5.  The MIL-STD Documents
+
+   The Internet community specifications for IP (RFC-791) and TCP (RFC-
+   793) and the DoD MIL-STD specifications are intended to describe
+   exactly the same protocols.  Any difference in the protocols
+   specified by these sets of documents should be reported to DCA and to
+   the IAB.  The RFCs and the MIL-STDs for IP and TCP differ in style
+   and level of detail.  It is strongly advised that the two sets of
+   documents be used together.
+
+   The IAB and the DoD MIL-STD specifications for the FTP, SMTP, and
+   Telnet protocols are essentially the same documents (RFCs 765, 821,
+   854).The MIL-STD versions have been edited slightly.  Note that the
+   current Internet specification for FTP is RFC-959.
+
+          Internet Protocol (IP)                      MIL-STD-1777
+          Transmission Control Protocol (TCP)         MIL-STD-1778
+          File Transfer Protocol (FTP)                MIL-STD-1780
+          Simple Mail Transfer Protocol (SMTP)        MIL-STD-1781
+          Telnet Protocol and Options (TELNET)        MIL-STD-1782
+
+5.  Explanation of Terms
+
+   There are two independent categorizations of protocols.  The first is
+   the state of standardization which is one of "standard", "draft
+   standard", "proposed", "experimental", or "historic".  The second is
+   the status of this protocol which is one of "required",
+   "recommended", "elective", or "not recommended".  One could expect a
+   particular protocol to move along the scale of status from elective
+   to required at the same time as it moves along the scale of
+   standardization from proposed to standard.
+
+   At any given time a protocol is a cell of the following matrix.
+   Protocols are likely to be in cells in about the following
+   proportions (indicated by the number of Xs).  Most will be on the
+   main diagonal.  A new protocol is most likely to start in the
+   (proposed, elective) cell, or the (experimental, not recommended)
+   cell.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                       [Page 5]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+                     Req   Rec   Ele   Not
+                   +-----+-----+-----+-----+
+           Std     | XXX |  XX |  X  |     |
+                   +-----+-----+-----+-----+
+           Draft   |     |  X  |  XX |     |
+                   +-----+-----+-----+-----+
+           Prop    |     |     | XXX |  X  |
+                   +-----+-----+-----+-----+
+           Expr    |     |     |  X  | XXX |
+                   +-----+-----+-----+-----+
+           Hist    |     |     |     | XXX |
+                   +-----+-----+-----+-----+
+
+
+   Some protocol are particular to hosts and some to gateways; a few
+   protocols are used in both.  The definitions of the terms below will
+   refer to a "system" which is either a host or a gateway (or both).
+   It should be clear from the context of the particular protocol which
+   types of systems are intended.
+
+5.1.  Definitions
+
+   5.1.1.  Standard Protocol
+
+      The IAB has established this as an official standard protocol for
+      the Internet.  These are separated into two groups: (1) IP
+      protocol and above, protocols that apply to the whole Internet;
+      and (2) network-specific protocols, generally specifications of
+      how to do IP on particular types of networks.
+
+   5.1.2.  Draft Standard Protocol
+
+      The IAB is actively considering this protocol as a possible
+      Standard Protocol.  Substantial and widespread testing and comment
+      is desired.  Comments and test results should be submitted to the
+      IAB.  There is a possibility that changes will be made in a Draft
+      Standard Protocol before it becomes a Standard Protocol.
+
+   5.1.3.  Proposed Protocol
+
+      These are protocol proposals that may be considered by the IAB for
+      standardization in the future.  Implementation and testing by
+      several groups is desirable.  Revisions of the protocol
+      specification are likely.
+
+   5.1.4.  Experimental Protocol
+
+      A system should not implement an experimental protocol unless it
+
+
+
+Internet Activities Board                                       [Page 6]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+      is participating in the experiment and has coordinated its use of
+      the protocol with the developer of the protocol.
+
+      Typically, experimental protocols are those that are developed as
+      part of a specific ongoing research project not related to an
+      operational service offering.  While they may be proposed as a
+      service protocol at a later stage, and thus become proposed,
+      draft, and then standard protocols, the designation of a protocol
+      as experimental is meant to suggest that the protocol, although
+      perhaps mature, is not intended for operational use.
+
+   5.1.5.  Historic Protocol
+
+      These are protocols that are unlikely to ever become standards in
+      the Internet either because they have been superseded by later
+      developments or due to lack of interest.  These are protocols that
+      are at an evolutionary dead end.
+
+   5.1.6.  Required Protocol
+
+      All systems must implement the required protocols.
+
+   5.1.7.  Recommended Protocol
+
+      All systems should implement the recommended protocols.
+
+   5.1.8.  Elective Protocol
+
+      A system may or may not implement an elective protocol. The
+      general notion is that if you are going to do something like this,
+      you must do exactly this.
+
+   5.1.9.  Not Recommended Protocol
+
+      These protocols are not recommended for general use.  This may be
+      because of their limited functionality, specialized nature, or
+      experimental or historic state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                       [Page 7]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+6.  The Protocols
+
+6.1.  Standard Protocols
+
+Protocol   Name                                      Status          RFC
+--------   ----                                      ------          ---
+           Assigned Numbers                          Required       1010
+           Gateway Requirements                      Required       1009
+IP         Internet Protocol                         Required        791
+            as amended by:
+             IP Subnet Extension                     Required        950
+             IP Broadcast Datagrams                  Required        919
+             IP Broadcast Datagrams with Subnets     Required        922
+ICMP       Internet Control Message Protocol         Required        792
+UDP        User Datagram Protocol                    Recommended     768
+TCP        Transmission Control Protocol             Recommended     793
+DOMAIN     Domain Name System                     Recommended  1034,1035
+TELNET     Telnet Protocol                           Recommended     854
+FTP        File Transfer Protocol                    Recommended     959
+SMTP       Simple Mail Transfer Protocol             Recommended     821
+MAIL       Format of Electronic Mail Messages        Recommended     822
+EGP        Exterior Gateway Protocol                 Recommended     904
+NETBIOS    NetBIOS Service Protocols                 Elective  1001,1002
+ECHO       Echo Protocol                             Recommended     862
+DISCARD    Discard Protocol                          Elective        863
+CHARGEN    Character Generator Protocol              Elective        864
+QUOTE      Quote of the Day Protocol                 Elective        865
+USERS      Active Users Protocol                     Elective        866
+DAYTIME    Daytime Protocol                          Elective        867
+TIME       Time Server Protocol                      Elective        868
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                       [Page 8]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+6.2.  Specific Standard Protocols
+
+Protocol   Name                                     Status           RFC
+--------   ----                                     ------           ---
+ARP        Address Resolution Protocol              Elective         826
+RARP       A Reverse Address Resolution Protocol    Elective         903
+IP-ARPA    Internet Protocol on ARPANET             Elective    BBN 1822
+IP-WB      Internet Protocol on Wideband Network    Elective         907
+IP-X25     Internet Protocol on X.25 Networks       Elective         877
+IP-E       Internet Protocol on Ethernet Networks   Elective         894
+IP-EE      Internet Protocol on Exp. Ethernet Nets  Elective         895
+IP-IEEE    Internet Protocol on IEEE 802            Elective        1042
+IP-DC      Internet Protocol on DC Networks         Elective         891
+IP-HC      Internet Protocol on Hyperchannnel       Elective        1044
+IP-ARC     Internet Protocol on ARCNET              Elective        1051
+IP-SLIP    Transmission of IP over Serial Lines     Elective        1055
+IP-NETBIOS Transmission of IP over NETBIOS          Elective        1088
+
+Note:  It is expected that a system will support one or more physical
+networks and for each physical network supported the appropriate
+protocols from the above list must be supported.  That is, it is
+elective to support any particular type of physical network, and for the
+physical networks actually supported it is required that they be
+supported exactly according to the protocols in the above list.
+
+6.3.  Draft Standard Protocols
+
+Protocol   Name                                     Status           RFC
+--------   ----                                     ------           ---
+SNMP       Simple Network Management Protocol       Recommended     1098
+CMOT       Common Management Information Services   Recommended     1095
+           and Protocol over TCP/IP
+MIB        Management Information Base              Recommended     1066
+SMI        Structure of Management Information      Recommended     1065
+NTP        Network Time Protocol                    Elective        1059
+IGMP       Internet Group Multicast Protocol        Recommended     1054
+BOOTP      Bootstrap Protocol                  Recommended 951,1048,1084
+
+The Internet Activities Board has designated two different network
+management protocols with the same status of "Draft Standard" and
+"Recommended".  The two protocols are the Common Management Information
+Services and Protocol over TCP/IP (CMOT) [RFC-1095] and the Simple
+Network Management Protocol (SNMP) [RFC-1098].  The IAB intends each of
+these two protocols to receive the attention of implementers and
+experimenters.  The IAB seeks reports of experience with these two
+protocols from system builders and users.  By this action, the IAB
+recommends that all IP and TCP implementations be network manageable
+(e.g., implement the Internet MIB [RFC-1066], and that implementations
+
+
+
+Internet Activities Board                                       [Page 9]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+that are network manageable are expected to adopt and implement at least
+one of these two Internet Draft Standards.
+
+6.4.  Proposed Protocols
+
+Protocol   Name                                     Status           RFC
+--------   ----                                     ------           ---
+SUN-NFS    Network File System Protocol             Elective        1094
+POP3       Post Office Protocol, Version 3          Elective   1081,1082
+RIP        Routing Information Protocol             Elective        1058
+SUN-RPC    Remote Procedure Call Protocol           Elective        1057
+PCMAIL     Pcmail Transport Protocol                Elective        1056
+VMTP       Versatile Message Transaction Protocol   Elective        1045
+NFILE      A File Access Protocol                   Elective        1037
+           Mapping between X.400 and RFC-822        Elective    987,1026
+STATSRV    Statistics Server                        Elective         996
+NNTP       Network News Transfer Protocol           Elective         977
+NICNAME    WhoIs Protocol                           Elective         954
+HOSTNAME   HOSTNAME Protocol                        Elective         953
+POP2       Post Office Protocol, Version 2          Elective         937
+SFTP       Simple File Transfer Protocol            Elective         913
+RLP        Resource Location Protocol               Elective         887
+RTELNET    Remote Telnet Service                    Elective         818
+TFTP       Trivial File Transfer Protocol           Elective         783
+FINGER     Finger Protocol                          Elective         742
+SUPDUP     SUPDUP Protocol                          Elective         734
+NETED      Network Standard Text Editor             Elective         569
+RJE        Remote Job Entry                         Elective         407
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 10]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+6.5.  Experimental Protocols
+
+Protocol   Name                                     Status           RFC
+--------   ----                                     ------           ---
+IP-DVMRP   IP Distance Vector Multicast Routing     Not Recommended 1075
+IP-MTU     IP MTU Discovery Options                 Not Recommended 1063
+NETBLT     Bulk Data Transfer Protocol              Not Recommended  998
+IMAP2      Interactive Mail Access Protocol         Not Recommended 1064
+COOKIE-JAR Authentication Scheme                    Not Recommended 1004
+IRTP       Internet Reliable Transaction Protocol   Not Recommended  938
+AUTH       Authentication Service                   Not Recommended  931
+RATP       Reliable Asynchronous Transfer Protocol  Not Recommended  916
+THINWIRE   Thinwire Protocol                        Not Recommended  914
+LDP        Loader Debugger Protocol                 Not Recommended  909
+RDP        Reliable Data Protocol                   Not Recommended  908
+ST         Stream Protocol                       Not Recommended IEN 119
+NVP-II     Network Voice Protocol               Not Recommended ISI memo
+
+6.6.  Historic Protocols
+
+Protocol   Name                                     Status           RFC
+--------   ----                                     ------           ---
+SGMP       Simple Gateway Monitoring Protocol       Not Recommended 1028
+HEMS       High Level Entity Management Protocol    Not Recommended 1021
+HMP        Host Monitoring Protocol                 Not Recommended  869
+GGP        Gateway Gateway Protocol                 Not Recommended  823
+CLOCK      DCNET Time Server Protocol               Not Recommended  778
+MPM        Internet Message Protocol                Not Recommended  759
+NETRJS     Remote Job Service                       Elective         740
+XNET       Cross Net Debugger                       Elective     IEN 158
+NAMESERVER Host Name Server Protocol             Not Recommended IEN 116
+MUX        Multiplexing Protocol                 Not Recommended IEN  90
+GRAPHICS   Graphics Protocol                  Not Recommended  NIC 24308
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 11]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+7.  Contacts
+
+7.1.  Internet Activities Board Contact
+
+      Contact:
+
+         Jon Postel
+         Deputy Internet Architect
+         USC Information Sciences Institute
+         4676 Admiralty Way
+         Marina del Rey, CA  90292-6695
+
+         1-213-822-1511
+
+         Postel@ISI.EDU
+
+   Please send your comments about this list of protocols and especially
+   about the Draft Standard Protocols to the Internet Activities Board
+   care of the Deputy Internet Architect.
+
+7.2.  Internet Assigned Numbers Authority Contact
+
+      Contact:
+
+         Joyce K. Reynolds
+         Internet Assigned Numbers Authority
+         USC Information Sciences Institute
+         4676 Admiralty Way
+         Marina del Rey, CA  90292-6695
+
+         1-213-822-1511
+
+         JKRey@ISI.EDU
+
+   The protocol standards are managed for the IAB by the Internet
+   Assigned Numbers Authority.
+
+   Please refer to the documents "Assigned Numbers" (RFC-1010) and
+   "Official Internet Protocols" (RFC-1011) for further information
+   about the status of protocol documents.  There are two documents that
+   summarize the requirements for host and gateways in the Internet,
+   "Host Requirements" (RFC in preparation) and "Gateway Requirements"
+   (RFC-1009).
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 12]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+      How to obtain the most recent edition of this "IAB Official
+      Protocol Standards" memo:
+
+         The file "in-notes/iab-standards.txt" may be copied via FTP
+         from the VENERA.ISI.EDU computer using the FTP username
+         "anonymous" and FTP password "guest".
+
+
+7.3.  Request for Comments Editor Contact
+
+      Contact:
+
+         Jon Postel
+         RFC Editor
+         USC Information Sciences Institute
+         4676 Admiralty Way
+         Marina del Rey, CA  90292-6695
+
+         1-213-822-1511
+
+         Postel@ISI.EDU
+
+   Documents may be submitted via electronic mail to the RFC Editor for
+   consideration for publication as RFC.  If you are not familiar with
+   the format or style requirements please request the "Instructions for
+   RFC Authors".  In general, the style of any recent RFC may be used as
+   a guide.
+
+7.4.  The Network Information Center and Requests for Comments Contact
+
+      Contact:
+
+         SRI International
+         DDN Network Information Center
+         333 Ravenswood Avenue
+         Menlo Park, CA  94025
+
+         1-800-235-3155
+         1-415-859-3695
+
+         NIC@SRI-NIC.ARPA
+
+   The Network Information Center (NIC) provides many information
+   services for the Internet community.  Among them is maintaining the
+   Requests for Comments (RFC) library.
+
+   RFCs can be obtained via FTP from SRI-NIC.ARPA with the pathname
+   RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC. A list
+
+
+
+Internet Activities Board                                      [Page 13]
+
+RFC 1100                     IAB Standards                    April 1989
+
+
+   of all RFCs may be obtained by copying the file RFC:RFC-INDEX.TXT.
+   Log in with FTP username ANONYMOUS and password GUEST.
+
+   The NIC also provides an automatic mail service for those sites which
+   cannot use FTP.  Address the request to SERVICE@SRI-NIC.ARPA and in
+   the subject field of the message indicate the RFC number, as in
+   "Subject: RFC nnnn".
+
+      How to obtain the most recent edition of this "IAB Official
+      Protocol Standards" memo:
+
+         The file RFC:IAB-STANDARDS.TXT may be copied via FTP from the
+         SRI-NIC.ARPA computer following the same procedures used to
+         obtain RFCs.
+
+Author's Address:
+
+   Jon Postel
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: (213) 822-1511
+
+   Email: Postel@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board                                      [Page 14]
+
\ No newline at end of file