summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1083.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1083.txt')
-rw-r--r--doc/rfc/rfc1083.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc1083.txt b/doc/rfc/rfc1083.txt
new file mode 100644
index 0000000..3954709
--- /dev/null
+++ b/doc/rfc/rfc1083.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group Internet Activities Board
+Request for Comments: 1083 December 1988
+
+
+ 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-March-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.
+
+ In cases where there is uncertainty as to the proper decision
+ concerning a protocol, the IAB may convene a special review committee
+
+
+
+Internet Activities Board [Page 1]
+
+RFC 1083 IAB Standards December 1988
+
+
+ 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
+ declare the protocol an official Internet standard.
+
+
+
+
+Internet Activities Board [Page 2]
+
+RFC 1083 IAB Standards December 1988
+
+
+ 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
+ particular protocol. This "IAB Official Protocol Standards" memo is
+ the reference for determining the correct RFC to refer to for the
+
+
+
+Internet Activities Board [Page 3]
+
+RFC 1083 IAB Standards December 1988
+
+
+ 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.
+
+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 1083 IAB Standards December 1988
+
+
+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.
+
+ 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.
+
+
+
+
+Internet Activities Board [Page 5]
+
+RFC 1083 IAB Standards December 1988
+
+
+ 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
+ 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,
+
+
+
+Internet Activities Board [Page 6]
+
+RFC 1083 IAB Standards December 1988
+
+
+ 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.
+
+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
+DOMAINS 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 Services Protocol 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 7]
+
+RFC 1083 IAB Standards December 1988
+
+
+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
+
+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 Monitoring Protocol Recommended 1067
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board [Page 8]
+
+RFC 1083 IAB Standards December 1988
+
+
+6.4. Proposed Protocols
+
+Protocol Name Status RFC
+-------- ---- ------ ---
+VMTP Versatile Message Transaction Protocol Elective 1045
+RIP Routing Information Protocol Elective 1058
+SUN-RPC Remote Procedure Call Protocol Elective 1057
+PCMAIL Pcmail Transport Protocol Elective 1056
+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 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
+
+6.5. Experimental Protocols
+
+Protocol Name Status RFC
+-------- ---- ------ ---
+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
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board [Page 9]
+
+RFC 1083 IAB Standards December 1988
+
+
+6.6. Historic Protocols
+
+Protocol Name Status RFC
+-------- ---- ------ ---
+SGMP Simple Gateway Monitoring Protocol Not Recommended 1028
+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
+
+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
+
+
+
+Internet Activities Board [Page 10]
+
+RFC 1083 IAB Standards December 1988
+
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Activities Board [Page 11]
+
+RFC 1083 IAB Standards December 1988
+
+
+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
+ 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 12]
+ \ No newline at end of file