From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1360.txt | 1851 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1851 insertions(+) create mode 100644 doc/rfc/rfc1360.txt (limited to 'doc/rfc/rfc1360.txt') diff --git a/doc/rfc/rfc1360.txt b/doc/rfc/rfc1360.txt new file mode 100644 index 0000000..e68c64e --- /dev/null +++ b/doc/rfc/rfc1360.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group Internet Architecture Board +Request for Comments: 1360 J. Postel, Editor +Obsoletes: RFCs 1280, 1250, September 1992 +1100, 1083, 1130, 1140, 1200 +STD: 1 + + + + 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 Architecture Board (IAB). + Distribution of this memo is unlimited. + +Table of Contents + + Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. The Standardization Process . . . . . . . . . . . . . . . . 2 + 2. The Request for Comments Documents . . . . . . . . . . . . . 5 + 3. Other Reference Documents . . . . . . . . . . . . . . . . . 6 + 3.1. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Gateway Requirements . . . . . . . . . . . . . . . . . . . 6 + 3.3. Host Requirements . . . . . . . . . . . . . . . . . . . . 6 + 3.4. The MIL-STD Documents . . . . . . . . . . . . . . . . . . 6 + 4. Explanation of Terms . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Definitions of Protocol State (Maturity Level) . . . . . . 8 + 4.1.1. Standard Protocol . . . . . . . . . . . . . . . . . . . 8 + 4.1.2. Draft Standard Protocol . . . . . . . . . . . . . . . . 9 + 4.1.3. Proposed Standard Protocol . . . . . . . . . . . . . . . 9 + 4.1.4. Experimental Protocol . . . . . . . . . . . . . . . . . 9 + 4.1.5. Informational Protocol . . . . . . . . . . . . . . . . . 9 + 4.1.6. Historic Protocol . . . . . . . . . . . . . . . . . . . 9 + 4.2. Definitions of Protocol Status (Requirement Level) . . . 10 + 4.2.1. Required Protocol . . . . . . . . . . . . . . . . . . 10 + 4.2.2. Recommended Protocol . . . . . . . . . . . . . . . . . 10 + 4.2.3. Elective Protocol . . . . . . . . . . . . . . . . . . 10 + 4.2.4. Limited Use Protocol . . . . . . . . . . . . . . . . . 10 + 4.2.5. Not Recommended Protocol . . . . . . . . . . . . . . . 10 + 5. The Standards Track . . . . . . . . . . . . . . . . . . . 10 + 5.1. The RFC Processing Decision Table . . . . . . . . . . . 10 + 5.2. The Standards Track Diagram . . . . . . . . . . . . . . 12 + 6. The Protocols . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. Recent Changes . . . . . . . . . . . . . . . . . . . . . 14 + 6.1.1. New RFCs . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1.2. Other Changes . . . . . . . . . . . . . . . . . . . . 19 + + + +Internet Architecture Board [Page 1] + +RFC 1360 IAB Standards September 1992 + + + 6.2. Standard Protocols . . . . . . . . . . . . . . . . . . . 21 + 6.3. Network-Specific Standard Protocols . . . . . . . . . . 22 + 6.4. Draft Standard Protocols . . . . . . . . . . . . . . . . 23 + 6.5. Proposed Standard Protocols . . . . . . . . . . . . . . 24 + 6.6. Telnet Options . . . . . . . . . . . . . . . . . . . . . 25 + 6.7. Experimental Protocols . . . . . . . . . . . . . . . . . 26 + 6.8. Informational Protocols . . . . . . . . . . . . . . . . 27 + 6.9. Historic Protocols . . . . . . . . . . . . . . . . . . . 28 + 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 7.1. IAB, IETF, and IRTF Contacts . . . . . . . . . . . . . . 29 + 7.1.1. Internet Architecture Board (IAB) Contact . . . . . . 29 + 7.1.2. Internet Engineering Task Force (IETF) Contact . . . . 29 + 7.1.3. Internet Research Task Force (IRTF) Contact . . . . . 30 + 7.2. Internet Assigned Numbers Authority (IANA) Contact . . . 31 + 7.3. Request for Comments Editor Contact . . . . . . . . . . 32 + 7.4. Network Information Center Contact . . . . . . . . . . . 32 + 7.5. Sources for Requests for Comments . . . . . . . . . . . 33 + 8. Security Considerations . . . . . . . . . . . . . . . . . 33 + 9. Author's Address . . . . . . . . . . . . . . . . . . . . . 33 + +Introduction + + Discussion of the standardization process and the RFC document series + is presented first, followed by an explanation of the terms. + Sections 6.2 - 6.9 contain the lists of protocols in each stage of + standardization. Finally come pointers to references and contacts + for further information. + + This memo is intended to be issued approximately quarterly; please be + sure the copy you are reading is current. 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 edition after 15-Jan-93. + + See Section 6.1 for a description of recent changes. In the official + lists in sections 6.2 - 6.9, an asterisk (*) next to a protocol + denotes that it is new to this document or has been moved from one + protocol level to another, or differs from the previous edition of + this document. + +1. The Standardization Process + + The Internet Architecture Board maintains this list of documents that + define standards for the Internet protocol suite. See RFC-1358 for + the charter of the IAB and RFC-1160 for an explanation of the role + and organization of the IAB and its subsidiary groups, the Internet + Engineering Task Force (IETF) and the Internet Research Task Force + (IRTF). Each of these groups has a steering group called the IESG + + + +Internet Architecture Board [Page 2] + +RFC 1360 IAB Standards September 1992 + + + and IRSG, respectively. The IAB 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. The definitive + description of the Internet standards process is found in RFC-1310. + + The majority of Internet protocol development and standardization + activity takes place in the working groups of the Internet + Engineering Task Force. + + Protocols which are to become standards in the Internet go through a + series of states or maturity levels (proposed standard, draft + standard, and standard) involving increasing amounts of scrutiny and + testing. When a protocol completes this process it is assigned a STD + number (see RFC-1311). At each step, the Internet Engineering + Steering Group (IESG) of the IETF must make a recommendation for + advancement of the protocol and the IAB must ratify it. If a + recommendation is not ratified, the protocol is remanded to the IETF + for further work. + + To allow time for the Internet community to consider and react to + standardization proposals, the IAB imposes a minimum delay of 6 + months before a proposed standard can be advanced to a draft standard + and 4 months before a draft standard can be promoted to standard. + + It is general IAB practice that no proposed standard can be promoted + to draft standard without at least two independent implementations + (and the recommendation of the IESG). Promotion from draft standard + to standard generally requires operational experience and + demonstrated interoperability of two or more implementations (and the + recommendation of the IESG). + + In cases where there is uncertainty as to the proper decision + concerning a protocol the IAB may convene a special review committee + consisting of experts from the IETF, IRTF and the IAB with the + purpose of recommending an explicit action to the IAB. + + Advancement of a protocol to proposed standard is an important step + since it marks a protocol as a candidate for eventual standardization + (it puts the protocol "on the standards track"). Advancement to + draft standard is a major step which warns the community that, unless + major objections are raised or flaws are discovered, the protocol is + likely to be advanced to standard in six months. + + Some protocols have been superseded by better ones or are otherwise + unused. Such protocols are still documented in this memorandum with + the designation "historic". + + + + +Internet Architecture Board [Page 3] + +RFC 1360 IAB Standards September 1992 + + + Because the IAB believes it is useful to document the results of + early protocol research and development work, some of the RFCs + document protocols which are still in an experimental condition. The + protocols are designated "experimental" in this memorandum. They + appear in this report as a convenience to the community and not as + evidence of their standardization. + + Other protocols, such as those developed by other standards + organizations, or by particular vendors, may be of interest or may be + recommended for use in the Internet. The specifications of such + protocols may be published as RFCs for the convenience of the + Internet community. These protocols are labeled "informational" in + this memorandum. + + In addition to the working groups of the IETF, protocol development + and experimentation may take place as a result of the work of the + research groups of the Internet Research Task Force, or the work of + other individuals interested in Internet protocol development. The + IAB encourages the documentation of such experimental work in the RFC + series, but none of this work is considered to be on the track for + standardization until the IESG has made a recommendation to advance + the protocol to the proposed standard state, and the IAB has approved + this step. + + A few protocols have achieved widespread implementation without the + approval of the IESG and the IAB. For example, some vendor protocols + have become very important to the Internet community even though they + have not been recommended by the IESG or ratified 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 terms "standard", + "draft standard", and "proposed standard" in any RFC or other + publication of Internet protocols to only those protocols which the + IAB has approved. + + In addition to a state (like "Proposed Standard"), a protocol is also + assigned a status, or requirement level, in this document. The + possible requirement levels ("Required", "Recommended", "Elective", + "Limited Use", and "Not Recommended") are defined in Section 4.2. + When a protocol is on the standards track, that is in the proposed + standard, draft standard, or standard state (see Section 5), the + status shown in Section 6 is the current status. For a proposed or + draft standard, however, the IAB will also endeavor to indicate the + eventual status this protocol will have after adoption as a standard. + + Few protocols are required to be implemented in all systems; this is + because there is such a variety of possible systems, for example, + + + +Internet Architecture Board [Page 4] + +RFC 1360 IAB Standards September 1992 + + + gateways, terminal servers, workstations, and multi-user hosts. The + requirement level shown in this document is only a one word label, + which may not be sufficient to characterize the implementation + requirements for a protocol in all situations. For some protocols, + this document contains an additional status paragraph (an + applicability statement). In addition, more detailed status + information is contained in separate requirements documents (see + Section 3). + +2. The Request for Comments Documents + + The documents called Request for Comments (or RFCs) are the working + notes of the "Network Working Group", that is 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. + + Notice: + + 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, and see RFC 1111). + + While RFCs are not refereed publications, they do receive technical + review from the task forces, individual technical experts, or the RFC + Editor, as appropriate. + + The RFC series comprises a wide range of documents, ranging from + informational documents of general interests to specifications of + standard Internet protocols. In cases where submission is intended + to document a proposed standard, draft standard, or standard + protocol, the RFC Editor will publish the document only with the + approval of both the IESG and the IAB. For documents describing + experimental work, the RFC Editor will notify the IESG before + publication, allowing for the possibility of review by the relevant + IETF working group or IRTF research group and provide those comments + to the author. See Section 5.1 for more detail. + + 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 + + + +Internet Architecture Board [Page 5] + +RFC 1360 IAB Standards September 1992 + + + the reference for determining the correct RFC for the current + specification of each protocol. + + The RFCs are available from the Network Information Center at SRI + International, and a number of other sites. For more information + about obtaining RFCs, see Sections 7.4 and 7.5. + +3. Other Reference Documents + + There are three other reference documents of interest in checking the + current status of protocol specifications and standardization. These + are the Assigned Numbers, 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 3.4. + +3.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-1340. + + Another document, Internet Numbers, lists the assigned IP network + numbers, and the autonomous system numbers. Internet Numbers was + most recently issued as RFC-1166. + +3.2. Gateway Requirements + + This document reviews the specifications that apply to gateways and + supplies guidance and clarification for any ambiguities. Gateway + Requirements is RFC-1009. A working group of the IETF is actively + preparing a revision. + +3.3. Host Requirements + + This pair of documents reviews and updates the specifications that + apply to hosts, and it supplies guidance and clarification for any + ambiguities. Host Requirements was issued as RFC-1122 and RFC-1123. + +3.4. 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 + + + +Internet Architecture Board [Page 6] + +RFC 1360 IAB Standards September 1992 + + + 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, along with RFC-1122 and RFC-1123. + + 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 (as modified by + RFC-1123). + + Note that these MIL-STD are now somewhat out of date. The Gateway + Requirements (RFC-1009) and Host Requirements (RFC-1122, RFC-1123) + take precedence over both earlier RFCs and the MIL-STDs. + + 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 + + These documents are available from the Naval Publications and Forms + Center. Requests can be initiated by telephone, telegraph, or mail; + however, it is preferred that private industry use form DD1425, if + possible. + + Naval Publications and Forms Center, Code 3015 + 5801 Tabor Ave + Philadelphia, PA 19120 + Phone: 1-215-697-3321 (order tape) + 1-215-697-4834 (conversation) + +4. Explanation of Terms + + There are two independent categorization of protocols. The first is + the "maturity level" or STATE of standardization, one of "standard", + "draft standard", "proposed standard", "experimental", + "informational" or "historic". The second is the "requirement level" + or STATUS of this protocol, one of "required", "recommended", + "elective", "limited use", or "not recommended". + + The status or requirement level is difficult to portray in a one word + label. These status labels should be considered only as an + indication, and a further description, or applicability statement, + should be consulted. + + When a protocol is advanced to proposed standard or draft standard, + it is labeled with a current status and when possible, the IAB also + + + +Internet Architecture Board [Page 7] + +RFC 1360 IAB Standards September 1992 + + + notes the status that the protocol is expected to have when it + reaches the standard state. + + At any given time a protocol occupies a cell of the following matrix. + Protocols are likely to be in cells in about the following + proportions (indicated by the relative number of Xs). A new protocol + is most likely to start in the (proposed standard, elective) cell, or + the (experimental, not recommended) cell. + + S T A T U S + Req Rec Ele Lim Not + +-----+-----+-----+-----+-----+ + Std | X | XXX | XXX | | | + S +-----+-----+-----+-----+-----+ + Draft | X | X | XXX | | | + T +-----+-----+-----+-----+-----+ + Prop | | X | XXX | | | + A +-----+-----+-----+-----+-----+ + Info | | X | XXX | XX | X | + T +-----+-----+-----+-----+-----+ + Expr | | | X | XXX | XX | + E +-----+-----+-----+-----+-----+ + Hist | | | | X | XXX | + +-----+-----+-----+-----+-----+ + + What is a "system"? + + Some protocols 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. + +4.1. Definitions of Protocol State + + Every protocol listed in this document is assigned to a "maturity + level" or STATE of standardization: "standard", "draft standard", + "proposed standard", "experimental", or "historic". + + 4.1.1. Standard Protocol + + The IAB has established this as an official standard protocol for + the Internet. These protocols are assigned STD numbers (see RFC- + 1311). 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 Architecture Board [Page 8] + +RFC 1360 IAB Standards September 1992 + + + 4.1.2. Draft Standard Protocol + + The IAB is actively considering this protocol as a possible + Standard Protocol. Substantial and widespread testing and comment + are 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. + + 4.1.3. Proposed Standard 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. Revision of the protocol + specification is likely. + + 4.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 an 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 standard, + draft standard, and then standard protocols, the designation of a + protocol as experimental may sometimes be meant to suggest that + the protocol, although perhaps mature, is not intended for + operational use. + + 4.1.5. Informational Protocol + + Protocols developed by other standard organizations, or vendors, + or that are for other reasons outside the purview of the IAB, may + be published as RFCs for the convenience of the Internet community + as informational protocols. Such protocols may in some cases also + be recommended for use in the Internet by the IAB. + + 4.1.6. 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. + + + + + + + + +Internet Architecture Board [Page 9] + +RFC 1360 IAB Standards September 1992 + + +4.2. Definitions of Protocol Status + + This document lists a "requirement level" or STATUS for each + protocol. The status is one of "required", "recommended", + "elective", "limited use", or "not recommended". + + 4.2.1. Required Protocol + + A system must implement the required protocols. + + 4.2.2. Recommended Protocol + + A system should implement the recommended protocols. + + 4.2.3. 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. There may be several elective protocols + in a general area, for example, there are several electronic mail + protocols, and several routing protocols. + + 4.2.4. Limited Use Protocol + + These protocols are for use in limited circumstances. This may be + because of their experimental state, specialized nature, limited + functionality, or historic state. + + 4.2.5. 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. + +5. The Standards Track + + This section discusses in more detail the procedures used by the RFC + Editor and the IAB in making decisions about the labeling and + publishing of protocols as standards. + +5.1. The RFC Processing Decision Table + + Here is the current decision table for processing submissions by the + RFC Editor. The processing depends on who submitted it, and the + status they want it to have. + + + + + + +Internet Architecture Board [Page 10] + +RFC 1360 IAB Standards September 1992 + + + +==========================================================+ + |**************| S O U R C E | + +==========================================================+ + | Desired | IAB | IESG | IRSG | Other | + | Status | | | | | + +==========================================================+ + | | | | | | + | Standard | Publish | Vote | Bogus | Bogus | + | or | (1) | (3) | (2) | (2) | + | Draft | | | | | + | Standard | | | | | + +--------------+----------+----------+----------+----------+ + | | | | | | + | | Publish | Vote | Refer | Refer | + | Proposed | (1) | (3) | (4) | (4) | + | Standard | | | | | + | | | | | | + +--------------+----------+----------+----------+----------+ + | | | | | | + | | Publish | Notify | Notify | Notify | + | Experimental | (1) | (5) | (5) | (5) | + | Protocol | | | | | + | | | | | | + +--------------+----------+----------+----------+----------+ + | | | | | | + | Information | Publish |Discretion|Discretion|Discretion| + | or Opinion | (1) | (6) | (6) | (6) | + | Paper | | | | | + | | | | | | + +==========================================================+ + + (1) Publish. + + (2) Bogus. Inform the source of the rules. RFCs specifying + Standard, or Draft Standard must come from the IAB, only. + + (3) Vote by the IAB. If approved then do Publish (1), else do + Refer (4). + + (4) Refer to an Area Director for review by a WG. Expect to see + the document again only after approval by the IESG and the + IAB. + + (5) Notify both the IESG and IRSG. If no concerns are raised in + two weeks then do Discretion (6), else RFC Editor to resolve + the concerns or do Refer (4). + + (6) RFC Editor's discretion. The RFC Editor decides if a review + + + +Internet Architecture Board [Page 11] + +RFC 1360 IAB Standards September 1992 + + + is needed and if so by whom. RFC Editor decides to publish or + not. + + Of course, in all cases the RFC Editor can request or make minor + changes for style, format, and presentation purposes. + + The IESG has designated the IESG Secretary as its agent for + forwarding documents with IESG approval and for registering concerns + in response to notifications (5) to the RFC Editor. Documents from + Area Directors or Working Group Chairs may be considered in the same + way as documents from "other". + +5.2. The Standards Track Diagram + + There is a part of the STATUS and STATE categorization that is called + the standards track. Actually, only the changes of state are + significant to the progression along the standards track, though the + status assignments may be changed as well. + + The states illustrated by single line boxes are temporary states, + those illustrated by double line boxes are long term states. A + protocol will normally be expected to remain in a temporary state for + several months (minimum six months for proposed standard, minimum + four months for draft standard). A protocol may be in a long term + state for many years. + + A protocol may enter the standards track only on the recommendation + of the IESG and by action of the IAB; and may move from one state to + another along the track only on the recommendation of the IESG and by + action of the IAB. That is, it takes both the IESG and the IAB to + either start a protocol on the track or to move it along. + + Generally, as the protocol enters the standards track a decision is + made as to the eventual STATUS, requirement level or applicability + (elective, recommended, or required) the protocol will have, although + a somewhat less stringent current status may be assigned, and it then + is placed in the the proposed standard STATE with that status. So + the initial placement of a protocol is into state 1. At any time the + STATUS decision may be revisited. + + + + + + + + + + + + +Internet Architecture Board [Page 12] + +RFC 1360 IAB Standards September 1992 + + + | + +<----------------------------------------------+ + | ^ + V 0 | 4 + +-----------+ +===========+ + | enter |-->----------------+-------------->|experiment | + +-----------+ | +=====+=====+ + | | + V 1 | + +-----------+ V + | proposed |-------------->+ + +--->+-----+-----+ | + | | | + | V 2 | + +<---+-----+-----+ V + | draft std |-------------->+ + +--->+-----+-----+ | + | | | + | V 3 | + +<---+=====+=====+ V + | standard |-------------->+ + +=====+=====+ | + | + V 5 + +=====+=====+ + | historic | + +===========+ + + The transition from proposed standard (1) to draft standard (2) can + only be by action of the IAB on the recommendation of the IESG and + only after the protocol has been proposed standard (1) for at least + six months. + + The transition from draft standard (2) to standard (3) can only be by + action of the IAB on the recommendation of the IESG and only after + the protocol has been draft standard (2) for at least four months. + + Occasionally, the decision may be that the protocol is not ready for + standardization and will be assigned to the experimental state (4). + This is off the standards track, and the protocol may be resubmitted + to enter the standards track after further work. There are other + paths into the experimental and historic states that do not involve + IAB action. + + Sometimes one protocol is replaced by another and thus becomes + historic, or it may happen that a protocol on the standards track is + in a sense overtaken by another protocol (or other events) and + becomes historic (state 5). + + + +Internet Architecture Board [Page 13] + +RFC 1360 IAB Standards September 1992 + + +6. The Protocols + + Subsection 6.1 lists recent RFCs and other changes. Subsections 6.2 + - 6.9 list the standards in groups by protocol state. + +6.1. Recent Changes + +6.1.1. New RFCs: + + 1361 - Simple Network Time Protocol (SNTP) + + This is an information document and does not specify any + level of standard. + + 1360 - This memo. + + 1359 - Connecting to the Internet What Connecting Institutions + Should Anticipate + + This is an information document and does not specify any + level of standard. + + 1358 - Charter of the Internet Architecture Board (IAB) + + This is an information document and does not specify any + level of standard. + + 1357 - A Format for E-mailing Bibliographic Records + + This is an information document and does not specify any + level of standard. + + 1356 - Multiprotocol Interconnect on X.25 and ISDN in the Packet + Mode + + A Proposed Standard protocol. + + 1355 - Privacy and Accuracy Issues in Network Information Center + Databases + + This is an information document and does not specify any + level of standard. + + 1354 - IP Forwarding Table MIB + + A Proposed Standard protocol. + + + + + +Internet Architecture Board [Page 14] + +RFC 1360 IAB Standards September 1992 + + + 1353 - Definitions of Managed Objects for Administration of SNMP + Parties + + A Proposed Standard protocol. + + 1352 - SNMP Security Protocols + + A Proposed Standard protocol. + + 1351 - SNMP Administrative Model + + A Proposed Standard protocol. + + 1350 - The TFTP Protocol (Revision 2) + + A Standard protocol. + + 1349 - Type of Service in the Internet Protocol Suite + + A Proposed Standard protocol. + + 1348 - DNS NSAP RRs + + An Experimental protocol. + + 1347 - TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal + for Internet Addressing and Routing + + This is an information document and does not specify any + level of standard. + + 1346 - Resource Allocation, Control, and Accounting for the Use of + Network Resources + + This is an information document and does not specify any + level of standard. + + 1345 - Character Mnemonics & Character Sets + + This is an information document and does not specify any + level of standard. + + 1344 - Implications of MIME for Internet Mail Gateways + + This is an information document and does not specify any + level of standard. + + + + + +Internet Architecture Board [Page 15] + +RFC 1360 IAB Standards September 1992 + + + 1343 - A User Agent Configuration Mechanism For Multimedia Mail + Format Information + + This is an information document and does not specify any + level of standard. + + 1342 - Representation of Non-ASCII Text in Internet Message + Headers + + A Proposed Standard protocol. + + 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms + for Specifying and Describing the Format of Internet + Message Bodies + + A Proposed Standard protocol. + + 1340 - Assigned Numbers + + This is an information document and does not specify any + level of standard. + + 1339 - Remote Mail Checking Protocol + + An Experimental protocol. + + 1338 - Supernetting: an Address Assignment and Aggregation + Strategy + + This is an information document and does not specify any + level of standard. + + 1337 - TIME-WAIT Assassination Hazards in TCP + + This is an information document and does not specify any + level of standard. + + 1336 - Who's Who in the Internet - Biographies of IAB, IESG and + IRSG Members + + This is an information document and does not specify any + level of standard. + + 1335 - A Two-Tier Address Structure for the Internet: A Solution + to the Problem of Address Space Exhaustion + + This is an information document and does not specify any + level of standard. + + + +Internet Architecture Board [Page 16] + +RFC 1360 IAB Standards September 1992 + + + 1334 - Not yet issued. + + 1333 - PPP Link Quality Monitoring + + A Proposed Standard protocol. + + 1332 - The PPP Internet Protocol Control Protocol (IPCP) + + A Proposed Standard protocol. + + 1331 - The Point-to-Point Protocol (PPP) for the Transmission of + Multi-protocol Datagrams over Point-to-Point Links + + A Proposed Standard protocol. + + 1330 - Recommendations for the Phase I Deployment of OSI Directory + Services (X.500) and OSI Message Handling Services (X.400) + + This is an information document and does not specify any + level of standard. + + 1329 - Thoughts on Address Resolution for Dual MAC FDDI Networks + + This is an information document and does not specify any + level of standard. + + 1328 - X.400 1988 to 1984 downgrading + + A Proposed Standard protocol. + + 1327 - Mapping between X.400(1988) / ISO 10021 and RFC 822 + + A Proposed Standard protocol. + + 1326 - Mutual Encapsulation Considered Dangerous + + This is an information document and does not specify any + level of standard. + + 1325 - FYI on Questions and Answers - Answers to Commonly asked + "New Internet User" Questions + + This is an information document and does not specify any + level of standard. + + + + + + + +Internet Architecture Board [Page 17] + +RFC 1360 IAB Standards September 1992 + + + 1324 - A Discussion on Computer Network Conferencing + + This is an information document and does not specify any + level of standard. + + 1323 - TCP Extensions for High Performance + + A Proposed Standard protocol. + + 1322 - A Unified Approach to Inter-Domain Routing + + This is an information document and does not specify any + level of standard. + + 1321 - The MD5 Message-Digest Algorithm + + This is an information document and does not specify any + level of standard. + + 1320 - The MD4 Message-Digest Algorithm + + This is an information document and does not specify any + level of standard. + + 1319 - The MD2 Message-Digest Algorithm + + This is an information document and does not specify any + level of standard. + + 1318 - Definitions of Managed Objects for Parallel-printer-like + Hardware Devices + + A Proposed Standard protocol. + + 1317 - Definitions of Managed Objects RS-232-like Hardware Devices + + A Proposed Standard protocol. + + 1316 - Definitions of Managed Objects for Character Stream Devices + + A Proposed Standard protocol. + + 1315 - Management Information Base for Frame Relay DTEs + + A Proposed Standard protocol. + + + + + + +Internet Architecture Board [Page 18] + +RFC 1360 IAB Standards September 1992 + + + 1314 - A File Format for the Exchange of Images in the Internet + + A Proposed Standard protocol. + + 1313 - Today's Programming for KRFC AM 1313 Internet Talk Radio + + This is an information document and does not specify any + level of standard. + + 1312 - Message Send Protocol 2 + + An Experimental protocol. + +6.1.2. Other Changes: + + The following are changes to protocols listed in the previous + edition. + + 1172 - The Point-to-Point Protocol (PPP) Initial Configuration + Options + + Moved to Historic (obsoleted by RFC-1331). + + 1113 - Privacy Enhancement for Internet Electronic Mail: Part I -- + Message Encipherment and Authentication Procedures + + Moved to Historic. + + 1114 - Privacy Enhancement for Internet Electronic Mail: Part II + -- Certificate-Based Key Management + + Moved to Historic. + + 1115 - Privacy Enhancement for Internet Electronic Mail: Part III + -- Algorithms, Modes, and Identifiers + + Moved to Historic. + + 1056 - PCMAIL: A Distributed Mail System for Personal Computers + + Moved to Historic. + + 1058 - Routing Information Protocol + + Advanced to Standard protocol. + + + + + + +Internet Architecture Board [Page 19] + +RFC 1360 IAB Standards September 1992 + + + 1037 - NFILE - A File Access Protocol + + Moved to Historic. + + 1026 - Addendum to RFC 987 (Mapping between X.400 and RFC-822) + + Moved to Historic (obsoleted by RFC-1327). + + 987 - Mapping between X.400 and RFC-822 + + Moved to Historic (obsoleted by RFC-1327). + + 953 - Hostname Server + + Moved to Historic. + + 913 - Simple File Transfer Protocol + + Moved to Historic. + + 734 - SUPDUP + + Moved to Historic. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Architecture Board [Page 20] + +RFC 1360 IAB Standards September 1992 + + +6.2. Standard Protocols + +Protocol Name Status RFC STD * +======== ===================================== ======== ==== === = +-------- IAB Official Protocol Standards Req 1360 1 * +-------- Assigned Numbers Req 1340 2 * +-------- Host Requirements - Communications Req 1122 3 +-------- Host Requirements - Applications Req 1123 3 +-------- Gateway Requirements Req 1009 4 +IP Internet Protocol Req 791 5 + as amended by:-------- +-------- IP Subnet Extension Req 950 5 +-------- IP Broadcast Datagrams Req 919 5 +-------- IP Broadcast Datagrams with Subnets Req 922 5 +ICMP Internet Control Message Protocol Req 792 5 +IGMP Internet Group Multicast Protocol Rec 1112 5 +UDP User Datagram Protocol Rec 768 6 +TCP Transmission Control Protocol Rec 793 7 +TELNET Telnet Protocol Rec 854,855 8 +FTP File Transfer Protocol Rec 959 9 +SMTP Simple Mail Transfer Protocol Rec 821 10 +MAIL Format of Electronic Mail Messages Rec 822 11 +CONTENT Content Type Header Field Rec 1049 11 +NTP Network Time Protocol Rec 1119 12 +DOMAIN Domain Name System Rec 1034,1035 13 +DNS-MX Mail Routing and the Domain System Rec 974 14 +SNMP Simple Network Management Protocol Rec 1157 15 +SMI Structure of Management Information Rec 1155 16 +MIB-II Management Information Base-II Rec 1213 17 +EGP Exterior Gateway Protocol Rec 904 18 +NETBIOS NetBIOS Service Protocols Ele 1001,1002 19 +ECHO Echo Protocol Rec 862 20 +DISCARD Discard Protocol Ele 863 21 +CHARGEN Character Generator Protocol Ele 864 22 +QUOTE Quote of the Day Protocol Ele 865 23 +USERS Active Users Protocol Ele 866 24 +DAYTIME Daytime Protocol Ele 867 25 +TIME Time Server Protocol Ele 868 26 +TFTP Trivial File Transfer Protocol Ele 1350 33* +RIP Routing Information Protocol Ele 1058 34* + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +Applicability Statements: + + IGMP -- The Internet Architecture Board intends to move towards + general adoption of IP multicasting, as a more efficient solution + + + +Internet Architecture Board [Page 21] + +RFC 1360 IAB Standards September 1992 + + + than broadcasting for many applications. The host interface has been + standardized in RFC-1112; however, multicast-routing gateways are in + the experimental stage and are not widely available. An Internet + host should support all of RFC-1112, except for the IGMP protocol + itself which is optional; see RFC-1122 for more details. Even + without IGMP, implementation of RFC-1112 will provide an important + advance: IP-layer access to local network multicast addressing. It + is expected that IGMP will become recommended for all hosts and + gateways at some future date. + + SMI, MIB-II SNMP -- The Internet Architecture Board recommends that + all IP and TCP implementations be network manageable. At the current + time, this implies implementation of the Internet MIB-II (RFC-1213), + and at least the recommended management protocol SNMP (RFC-1157). + +6.3. Network-Specific Standard Protocols + +Protocol Name State Status RFC +======== ===================================== ======= ====== ===== +IP-FR Multiprotocol over Frame Relay Prop Ele 1294 +IP-SMDS Transmission of IP Datagrams over SMDS Prop Ele 1209 +ARP Address Resolution Protocol Std Ele 826 +RARP A Reverse Address Resolution Protocol Std Ele 903 +IP-ARPA Internet Protocol on ARPANET Std Ele BBN1822 +IP-WB Internet Protocol on Wideband Network Std Ele 907 +IP-X25 Internet Protocol on X.25 Networks Std Ele 877 +IP-E Internet Protocol on Ethernet Networks Std Ele 894 +IP-EE Internet Protocol on Exp. Ethernet Nets Std Ele 895 +IP-IEEE Internet Protocol on IEEE 802 Std Ele 1042 +IP-DC Internet Protocol on DC Networks Std Ele 891 +IP-HC Internet Protocol on Hyperchannel Std Ele 1044 +IP-ARC Internet Protocol on ARCNET Std Ele 1051 +IP-SLIP Transmission of IP over Serial Lines Std Ele 1055 +IP-NETBIOS Transmission of IP over NETBIOS Std Ele 1088 +IP-IPX Transmission of 802.2 over IPX Networks Std Ele 1132 +IP-FDDI Transmission of IP over FDDI Draft Ele 1188 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +Applicability Statements: + + 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. See + + + +Internet Architecture Board [Page 22] + +RFC 1360 IAB Standards September 1992 + + + also the Host and Gateway Requirements RFCs for more specific + information on network-specific ("link layer") protocols. + +6.4. Draft Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +FINGER Finger Protocol Elective 1288 +BGP3 Border Gateway Protocol 3 (BGP-3) Elective 1267,1268 +OSPF2 Open Shortest Path First Routing V2 Elective 1247 +POP3 Post Office Protocol, Version 3 Elective 1225 +Concise-MIB Concise MIB Definitions Elective 1212 +IP-FDDI Internet Protocol on FDDI Networks Elective 1188 +TOPT-LINE Telnet Linemode Option Elective 1184 +PPP Point to Point Protocol Elective 1171 +BOOTP Bootstrap Protocol Recommended 951,1084 +TP-TCP ISO Transport Service on top of the TCP Elective 1006 +NICNAME WhoIs Protocol Elective 954 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +Applicability Statements: + + RIP -- The Routing Information Protocol (RIP) is widely implemented + and used in the Internet. However, both implementors and users + should be aware that RIP has some serious technical limitations as a + routing protocol. The IETF is currently developing several + candidates for a new standard "open" routing protocol with better + properties than RIP. The IAB urges the Internet community to track + these developments, and to implement the new protocol when it is + standardized; improved Internet service will result for many users. + + TP-TCP -- As OSI protocols become more widely implemented and used, + there will be an increasing need to support interoperation with the + TCP/IP protocols. The Internet Engineering Task Force is formulating + strategies for interoperation. RFC-1006 provides one interoperation + mode, in which TCP/IP is used to emulate TP0 in order to support OSI + applications. Hosts that wish to run OSI connection-oriented + applications in this mode should use the procedure described in RFC- + 1006. In the future, the IAB expects that a major portion of the + Internet will support both TCP/IP and OSI (inter-)network protocols + in parallel, and it will then be possible to run OSI applications + across the Internet using full OSI protocol "stacks". + + PPP -- Point to Point Protocol is a method of sending IP over serial + lines, which are a type of physical network. It is anticipated that + PPP will be advanced to the network-specifics standard protocol state + + + +Internet Architecture Board [Page 23] + +RFC 1360 IAB Standards September 1992 + + + in the future. + +6.5. Proposed Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== + X.25 and ISDN in the Packet Mode Elective 1356* +TABLE-MIB IP Forwarding Table MIB Elective 1354* +------- Administration of SNMP Elective 1353* +SNMP-SEC SNMP Security Protocols Elective 1352* +SNMP-ADMIN SNMP Administrative Model Elective 1351* +TOS Type of Service in the Internet... Elective 1349* +------- Representation of Non-ASCII Text... Elective 1342* +MIME Multipurpose Internet Mail Extensions Elective 1341* +PPP-LINK PPP Link Quality Monitoring Elective 1333* +PPP Point-to-Point Protocol (PPP) Elective 1331* +------- X.400 1988 to 1984 downgrading Elective 1328* +------- Mapping between X.400(1988)... Elective 1327* +TCP-EXT TCP Extensions for High Performance Elective 1323* +------- Def. Man. Objs Parallel-printer-like... Elective 1318* +------- Def. Man Objs RS-232-like... Elective 1317* +------- Def. Man. Objs. Character Stream... Elective 1316* +FRAME-MIB Management Information Base for Frame.. Elective 1315* +NETFAX File Format for the Exchange of Images.. Elective 1314* +SIP-MIB SIP Interface Type MIB Elective 1304 +IARP Inverse Address Resolution Protocol Elective 1293 +DECNET-MIB DECNET MIB Elective 1289 +BRIDGE-MIB BRIDGE-MIB Elective 1286 +FDDI-MIB FDDI-MIB Elective 1285 +ETHER-MIB Ethernet MIB Elective 1284 +------- Encoding Network Addresses... Elective 1277 +------- Replication and Distributed Operations.. Elective 1276 +------- COSINE and Internet X.500 Schema... Elective 1274 +RMON-MIB Remote Network Monitoring MIB Elective 1271 +BGP-MIB Border Gateway Protocol MIB (Version 3) Elective 1269 +ICMP-ROUT ICMP Router Discovery Messages Elective 1256 +OSPF-MIB OSPF Version 2 MIB Elective 1253 +IPSO DoD Security Options for IP Elective 1108 +AT-MIB Appletalk MIB Elective 1243 +OSI-UDP OSI TS on UDP Elective 1240 +STD-MIBs Reassignment of Exp MIBs to Std MIBs Elective 1239 +OSI-NSAP Guidelines for OSI NSAP Allocation Elective 1237 +IPX-IP Tunneling IPX Traffic through IP Nets Elective 1234 +DS3-MIB DS3 Interface Objects Elective 1233 +DS1-MIB DS1 Interface Objects Elective 1232 +802.5-MIB IEEE 802.5 Token Ring MIB Elective 1231 +802.4-MIP IEEE 802.4 Token Bus MIB Elective 1230 +GINT-MIB Extensions to the Generic-Interface MIB Elective 1229 + + + +Internet Architecture Board [Page 24] + +RFC 1360 IAB Standards September 1992 + + +PPP-EXT PPP Extensions for Bridging Elective 1220 +OIM-MIB-II OSI Internet Management: MIB-II Elective 1214 +IP-SMDS IP Datagrams over the SMDS Service Elective 1209 +IP-ARCNET Transmitting IP Traffic over ARCNET Nets Elective 1201 +IS-IS OSI IS-IS for TCP/IP Dual Environments Elective 1195 +IP-MTU Path MTU Discovery Elective 1191 +CMOT Common Management Information Services.. Elective 1189 +IP-CMPRS Compressing TCP/IP Headers Elective 1144 +ISO-TS-ECHO Echo for ISO-8473 Elective 1139 +SUN-NFS Network File System Protocol Elective 1094 +SUN-RPC Remote Procedure Call Protocol Elective 1057 +NNTP Network News Transfer Protocol Elective 977 +RLP Resource Location Protocol Elective 887 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +Applicability Statements: + + IP-SMDS and IP-ARCNET -- These define methods of sending IP over + particular network types. It is anticipated that these will be + advanced to the network specific standard protocol state in the + future. + +6.6. Telnet Options + +For convenience, all the Telnet Options are collected here with both +their state and status. + +Protocol Name Number State Status RFC STD +======== ===================================== ===== ====== ==== ==== +TOPT-BIN Binary Transmission 0 Std Rec 856 27 +TOPT-ECHO Echo 1 Std Rec 857 28 +TOPT-RECN Reconnection 2 Prop Ele ... +TOPT-SUPP Suppress Go Ahead 3 Std Rec 858 29 +TOPT-APRX Approx Message Size Negotiation 4 Prop Ele ... +TOPT-STAT Status 5 Std Rec 859 30 +TOPT-TIM Timing Mark 6 Std Rec 860 31 +TOPT-REM Remote Controlled Trans and Echo 7 Prop Ele 726 +TOPT-OLW Output Line Width 8 Prop Ele ... +TOPT-OPS Output Page Size 9 Prop Ele ... +TOPT-OCRD Output Carriage-Return Disposition 10 Prop Ele 652 +TOPT-OHT Output Horizontal Tabstops 11 Prop Ele 653 +TOPT-OHTD Output Horizontal Tab Disposition 12 Prop Ele 654 +TOPT-OFD Output Formfeed Disposition 13 Prop Ele 655 +TOPT-OVT Output Vertical Tabstops 14 Prop Ele 656 +TOPT-OVTD Output Vertical Tab Disposition 15 Prop Ele 657 +TOPT-OLD Output Linefeed Disposition 16 Prop Ele 658 + + + +Internet Architecture Board [Page 25] + +RFC 1360 IAB Standards September 1992 + + +TOPT-EXT Extended ASCII 17 Prop Ele 698 +TOPT-LOGO Logout 18 Prop Ele 727 +TOPT-BYTE Byte Macro 19 Prop Ele 735 +TOPT-DATA Data Entry Terminal 20 Prop Ele 1043 +TOPT-SUP SUPDUP 21 Prop Ele 734 +TOPT-SUPO SUPDUP Output 22 Prop Ele 749 +TOPT-SNDL Send Location 23 Prop Ele 779 +TOPT-TERM Terminal Type 24 Prop Ele 1091 +TOPT-EOR End of Record 25 Prop Ele 885 +TOPT-TACACS TACACS User Identification 26 Prop Ele 927 +TOPT-OM Output Marking 27 Prop Ele 933 +TOPT-TLN Terminal Location Number 28 Prop Ele 946 +TOPT-3270 Telnet 3270 Regime 29 Prop Ele 1041 +TOPT-X.3 X.3 PAD 30 Prop Ele 1053 +TOPT-NAWS Negotiate About Window Size 31 Prop Ele 1073 +TOPT-TS Terminal Speed 32 Prop Ele 1079 +TOPT-RFC Remote Flow Control 33 Prop Ele 1080 +TOPT-LINE Linemode 34 Draft Ele 1184 +TOPT-XDL X Display Location 35 Prop Ele 1096 +TOPT-EXTOP Extended-Options-List 255 Std Rec 861 32 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +6.7. Experimental Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +DNS NSAP DNS NSAP RRs Elective 1348* +RMCP Remote Mail Checking Protocol Elective 1339* +MSP2 Message Send Protocol 2 Elective 1312* +DSLCP Dynamically Switched Link Control Elective 1307 +-------- X.500 and Domains Elective 1279 +SNMP-OSI SNMP over OSI Elective 1283 +IN-ENCAP Internet Encapsulation Protocol Limited Use 1241 +CLNS-MIB CLNS-MIB Limited Use 1238 +CFDP Coherent File Distribution Protocol Limited Use 1235 +SNMP-DPI SNMP Distributed Program Interface Limited Use 1228 +SNMP-MUX SNMP MUX Protocol and MIB Limited Use 1227 +IP-AX25 IP Encapsulation of AX.25 Frames Limited Use 1226 +ALERTS Managing Asynchronously Generated Alerts Limited Use 1224 +MPP Message Posting Protocol Limited Use 1204 +ST-II Stream Protocol Limited Use 1190 +SNMP-BULK Bulk Table Retrieval with the SNMP Limited Use 1187 +DNS-RR New DNS RR Definitions Limited Use 1183 +NTP-OSI NTP over OSI Remote Operations Limited Use 1165 +EHF-MAIL Encoding Header Field for Mail Elective 1154 +DMF-MAIL Digest Message Format for Mail Elective 1153 + + + +Internet Architecture Board [Page 26] + +RFC 1360 IAB Standards September 1992 + + +RDP Reliable Data Protocol Limited Use 908,1151 +-------- Mapping between X.400(88) and RFC-822 Elective 1148 +TCP-ACO TCP Alternate Checksum Option Not Recommended 1146 +-------- Mapping full 822 to Restricted 822 Elective 1137 +IP-DVMRP IP Distance Vector Multicast Routing Not Recommended 1075 +TCP-LDP TCP Extensions for Long Delay Paths Limited Use 1072 +IMAP2 Interactive Mail Access Protocol Limited Use 1176,1064 +IMAP3 Interactive Mail Access Protocol Limited Use 1203 +VMTP Versatile Message Transaction Protocol Elective 1045 +COOKIE-JAR Authentication Scheme Not Recommended 1004 +NETBLT Bulk Data Transfer Protocol Not Recommended 998 +IRTP Internet Reliable Transaction Protocol Not Recommended 938 +AUTH Authentication Service Not Recommended 931 +LDP Loader Debugger Protocol Not Recommended 909 +NVP-II Network Voice Protocol Limited Use ISI-memo +PVP Packet Video Protocol Limited Use ISI-memo + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +6.8. Informational Protocols + +Protocol Name Status RFC +======= ==================================== =============== ===== +------- Replication Requirements... Elective 1275* +PCMAIL Pcmail Transport Protocol Elective 1056* +MTP Multicast Transport Protocol Elective 1301 +SNMP-IPX SNMP over IPX Elective 1298 +BSD Login BSD Login Elective 1282 +DIXIE DIXIE Protocol Specification Limited Use 1249 +IP-X.121 IP to X.121 Address Mapping for DDN Limited Use 1236 +OSI-HYPER OSI and LLC1 on HYPERchannel Limited Use 1223 +HAP2 Host Access Protocol Limited Use 1221 +SUBNETASGN On the Assignment of Subnet Numbers Limited Use 1219 +SNMP-TRAPS Defining Traps for use with SNMP Limited Use 1215 +DAS Directory Assistance Service Limited Use 1202 +MD4 MD4 Message Digest Algorithm Limited Use 1186 +LPDP Line Printer Daemon Protocol Limited Use 1179 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + + + + + + + + + + +Internet Architecture Board [Page 27] + +RFC 1360 IAB Standards September 1992 + + +6.9. Historic Protocols + +Protocol Name Status RFC +======= ===================================== ============== ===== +PPP-INIT PPP Initial Configuration Options Not Recommended 1172* +MSP Message Send Protocol Not Recommended 1159* +-------- Mail Privacy: Procedures Not Recommended 1113* +-------- Mail Privacy: Key Management Not Recommended 1114* +-------- Mail Privacy: Algorithms Not Recommended 1115* +-------- Mapping X.400(84) and RFC-822 Not Recommended 987,1026* +NFILE A File Access Protocol Elective 1037* +HOSTNAME HOSTNAME Protocol Elective 953* +SFTP Simple File Transfer Protocol Elective 913* +SUPDUP SUPDUP Protocol Elective 734* +BGP Border Gateway Protocol Not Recommended 1163,1164 +MIB-I MIB-I Not Recommended 1156 +SGMP Simple Gateway Monitoring Protocol Not Recommended 1028 +HEMS High Level Entity Management Protocol Not Recommended 1021 +STATSRV Statistics Server Not Recommended 996 +POP2 Post Office Protocol, Version 2 Not Recommended 937 +RATP Reliable Asynchronous Transfer Protocol Not Recommended 916 +HFEP Host - Front End Protocol Not Recommended 929 +THINWIRE Thinwire Protocol Not Recommended 914 +HMP Host Monitoring Protocol Not Recommended 869 +GGP Gateway Gateway Protocol Not Recommended 823 +RTELNET Remote Telnet Service Not Recommended 818 +CLOCK DCNET Time Server Protocol Not Recommended 778 +MPM Internet Message Protocol Not Recommended 759 +NETRJS Remote Job Service Not Recommended 740 +NETED Network Standard Text Editor Not Recommended 569 +RJE Remote Job Entry Not Recommended 407 +XNET Cross Net Debugger Not Recommended 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 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + + + + + + + + + + + + + +Internet Architecture Board [Page 28] + +RFC 1360 IAB Standards September 1992 + + +7. Contacts + +7.1. IAB, IETF, and IRTF Contacts + + 7.1.1. Internet Architecture Board (IAB) Contact + + Please send your comments about this list of protocols and especially + about the Draft Standard Protocols to the Internet Architecture Board + care of Bob Braden, IAB Executive Director. + + Contacts: + + Bob Braden + Executive Director of the IAB + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + 1-310-822-1511 + + Braden@ISI.EDU + + A. Lyman Chapin + Chair of the IAB + Bolt, Beranek & Newman + Mail Stop 20/5b + 150 Cambridge Park Drive + Cambridge, MA 02140 + + 1-617-873-3133 + + Lyman@BBN.COM + + 7.1.2. Internet Engineering Task Force (IETF) Contact + + Contacts: + + Phill Gross + Chair of the IETF + Advanced Network and Services + 100 Clearbrook Road + Elmsford, NY 10523 + + 1-914-789-5300 + + PGross@NRI.RESTON.VA.US + + + + + +Internet Architecture Board [Page 29] + +RFC 1360 IAB Standards September 1992 + + + Greg Vaudreuil + IESG Secretary + Corporation for National Research Initiatives + 1895 Preston White Drive, Suite 100 + Reston, VA 22091 + + 1-703-620-8990 + + gvaudre@NRI.RESTON.VA.US + + Steve Coya + Executive Director of the IETF + Corporation for National Research Initiatives + 1895 Preston White Drive, Suite 100 + Reston, VA 22091 + + 1-703-620-8990 + + scoya@NRI.RESTON.VA.US + + + 7.1.3. Internet Research Task Force (IRTF) Contact + + Contact: + + Jon Postel + Chair of the IRTF + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + 1-310-822-1511 + + Postel@ISI.EDU + + + + + + + + + + + + + + + + + +Internet Architecture Board [Page 30] + +RFC 1360 IAB Standards September 1992 + + +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-310-822-1511 + + IANA@ISI.EDU + + The protocol standards are managed for the IAB by the Internet + Assigned Numbers Authority. + + Please refer to the document "Assigned Numbers" (RFC-1340) 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-1122 and RFC-1123) + 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". + + + + + + + + + + + + + + + + + + + + + + +Internet Architecture Board [Page 31] + +RFC 1360 IAB Standards September 1992 + + +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-310-822-1511 + + RFC-Editor@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 Distribution Contact + + Contact: + + Network Solutions + Attn: Network Information Center + 14200 Park Meadow Drive + Suite 200 + Chantilly, VA 22021 + + Help Desk Hours of Operation: 7:00 am to 7:00 pm Eastern Time + + 1-800-365-3642 (1-800-365-DNIC) + 1-703-802-4535 + Fax Number: 1-703-802-8376 + + NIC@NIC.DDN.MIL + + The Network Information Center (NIC) provides many information + services for the Internet community. Among them is maintaining the + Requests for Comments (RFC) library. + + + + + + + + + +Internet Architecture Board [Page 32] + +RFC 1360 IAB Standards September 1992 + + +7.5. Sources for Requests for Comments + + Details on obtaining RFCs via FTP or EMAIL may be obtained by sending + an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: + ways_to_get_rfcs". For example: + + To: rfc-info@ISI.EDU + Subject: getting rfcs + + help: ways_to_get_rfcs + +8. Security Considerations + + Security issues are not addressed in this memo. + +9. Author's Address + + Jon Postel + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: 310-822-1511 + Fax: 310-823-6714 + + Email: Postel@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Architecture Board [Page 33] + \ No newline at end of file -- cgit v1.2.3