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/rfc1410.txt | 1963 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1963 insertions(+) create mode 100644 doc/rfc/rfc1410.txt (limited to 'doc/rfc/rfc1410.txt') diff --git a/doc/rfc/rfc1410.txt b/doc/rfc/rfc1410.txt new file mode 100644 index 0000000..3af5f34 --- /dev/null +++ b/doc/rfc/rfc1410.txt @@ -0,0 +1,1963 @@ + + + + + + +Network Working Group Internet Architecture Board +Request for Comments: 1410 J. Postel, Editor +Obsoletes: RFCs 1360, 1280, 1250, March 1993 +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) . . . 9 + 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 . . . . . . . . . . . . . . . . . . . . 21 + 6.2. Standard Protocols . . . . . . . . . . . . . . . . . . . 22 + + + +Internet Architecture Board [Page 1] + +RFC 1410 IAB Standards March 1993 + + + 6.3. Network-Specific Standard Protocols . . . . . . . . . . 24 + 6.4. Draft Standard Protocols . . . . . . . . . . . . . . . . 25 + 6.5. Proposed Standard Protocols . . . . . . . . . . . . . . 25 + 6.6. Telnet Options . . . . . . . . . . . . . . . . . . . . . 27 + 6.7. Experimental Protocols . . . . . . . . . . . . . . . . . 28 + 6.8. Informational Protocols . . . . . . . . . . . . . . . . 29 + 6.9. Historic Protocols . . . . . . . . . . . . . . . . . . . 30 + 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 7.1. IAB, IETF, and IRTF Contacts . . . . . . . . . . . . . . 31 + 7.1.1. Internet Architecture Board (IAB) Contact . . . . . . 31 + 7.1.2. Internet Engineering Task Force (IETF) Contact . . . . 31 + 7.1.3. Internet Research Task Force (IRTF) Contact . . . . . 32 + 7.2. Internet Assigned Numbers Authority (IANA) Contact . . . 33 + 7.3. Request for Comments Editor Contact . . . . . . . . . . 34 + 7.4. Network Information Center Contact . . . . . . . . . . . 34 + 7.5. Sources for Requests for Comments . . . . . . . . . . . 35 + 8. Security Considerations . . . . . . . . . . . . . . . . . 35 + 9. Author's Address . . . . . . . . . . . . . . . . . . . . . 35 + +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 31-July-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 + and IRSG, respectively. The IAB provides these standards with the + + + +Internet Architecture Board [Page 2] + +RFC 1410 IAB Standards March 1993 + + + 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". + + Because the IAB believes it is useful to document the results of + + + +Internet Architecture Board [Page 3] + +RFC 1410 IAB Standards March 1993 + + + 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, + gateways, terminal servers, workstations, and multi-user hosts. The + + + +Internet Architecture Board [Page 4] + +RFC 1410 IAB Standards March 1993 + + + 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 + the reference for determining the correct RFC for the current + + + +Internet Architecture Board [Page 5] + +RFC 1410 IAB Standards March 1993 + + + 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 + specified by these sets of documents should be reported to DCA and to + + + +Internet Architecture Board [Page 6] + +RFC 1410 IAB Standards March 1993 + + + 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 + notes the status that the protocol is expected to have when it + + + +Internet Architecture Board [Page 7] + +RFC 1410 IAB Standards March 1993 + + + 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 | | | | | | + T +-----+-----+-----+-----+-----+ + Expr | | | | XXX | | + E +-----+-----+-----+-----+-----+ + Hist | | | | | 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 1410 IAB Standards March 1993 + + + 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. + + 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. + +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". + + + +Internet Architecture Board [Page 9] + +RFC 1410 IAB Standards March 1993 + + + 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 1410 IAB Standards March 1993 + + + +==========================================================+ + |**************| 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 1410 IAB Standards March 1993 + + + 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 1410 IAB Standards March 1993 + + + | + +<----------------------------------------------+ + | ^ + 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 1410 IAB Standards March 1993 + + +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: + + 1436 - The Internet Gopher Protocol + + This is an information document and does not specify any + level of standard. + + 1435 - IESG Advice from Experience with Path MTU Discovery + + This is an information document and does not specify any + level of standard. + + 1434 - Data Link Switching: Switch-to-Switch Protocol + + This is an information document and does not specify any + level of standard. + + 1433 - Directed ARP + + An Experimental protocol. + + 1432 - Recent Internet Books + + This is an information document and does not specify any + level of standard. + + 1431 - DUA Metrics + + This is an information document and does not specify any + level of standard. + + 1430 - A Strategic Plan for Deploying an Internet X.500 Directory + Service + + This is an information document and does not specify any + level of standard. + + 1429 - Listserv Distribute Protocol + + This is an information document and does not specify any + level of standard. + + + +Internet Architecture Board [Page 14] + +RFC 1410 IAB Standards March 1993 + + + 1428 - Transition of Internet Mail from Just-Send-8 to 8bit- + SMTP/MIME + + This is an information document and does not specify any + level of standard. + + 1427 - SMTP Service Extension for Message Size Declaration + + A Proposed Standard protocol. + + 1426 - SMTP Service Extension for 8bit-MIMEtransport + + A Proposed Standard protocol. + + 1425 - SMTP Service Extensions + + A Proposed Standard protocol. + + 1424 - Privacy Enhancement for Internet Electronic Mail: Part IV: + Key Certification and Related Services + + A Proposed Standard protocol. + + 1423 - Privacy Enhancement for Internet Electronic Mail: Part III: + Algorithms, Modes, and Identifiers + + A Proposed Standard protocol. + + 1422 - Privacy Enhancement for Internet Electronic Mail: Part II: + Certificate-Based Key Management + + A Proposed Standard protocol. + + 1421 - Privacy Enhancement for Internet Electronic Mail: Part I: + Message Encryption and Authentication Procedures + + A Proposed Standard protocol. + + 1420 - SNMP over IPX + + A Proposed Standard protocol. + + 1419 - SNMP over AppleTalk + + A Proposed Standard protocol. + + + + + + +Internet Architecture Board [Page 15] + +RFC 1410 IAB Standards March 1993 + + + 1418 - SNMP over OSI + + A Proposed Standard protocol. + + 1417 - NADF Standing Documents: A Brief Overview + + This is an information document and does not specify any + level of standard. + + 1416 - Telnet Authentication Option + + An Experimental protocol. + + 1415 - FTP-FTAM Gateway Specification + + A Proposed Standard protocol. + + 1414 - Identification MIB + + A Proposed Standard protocol. + + 1413 - Identification Protocol + + A Proposed Standard protocol. + + 1412 - Telnet Authentication: SPX + + An Experimental protocol. + + 1411 - Telnet Authentication: Kerberos Version 4 + + An Experimental protocol. + + 1410 - This memo. + + 1409 - Telnet Authentication Option + + An Experimental protocol. + + 1408 - Telnet Environment Option + + A Proposed Standard protocol. + + 1407 - Definitions of Managed Objects for the DS3/E3 Interface + Type + + A Proposed Standard protocol. + + + + +Internet Architecture Board [Page 16] + +RFC 1410 IAB Standards March 1993 + + + 1406 - Definitions of Managed Objects for the DS1 and E1 Interface + Types + + A Proposed Standard protocol. + + 1405 - Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) + + An Experimental protocol. + + 1404 - A Model for Common Operational Statistics + + This is an information document and does not specify any + level of standard. + + 1403 - BGP OSPF Interaction + + A Proposed Standard protocol. + + 1402 - There's Gold in them thar Networks! or Searching for + Treasure in all the Wrong Places + + This is an information document and does not specify any + level of standard. + + 1401 - Correspondence between the IAB and DISA on the use of DNS + throughout the Internet + + This is an information document and does not specify any + level of standard. + + 1400 - Not yet issued. + + 1399 - Not yet issued. + + 1398 - Definitions of Managed Objects for the Ethernet-like + Interface Types + + A Draft Standard protocol. + + 1397 - Default Route Advertisement In BGP2 And BGP3 Versions Of + The Border Gateway Protocol + + A Proposed Standard protocol. + + + + + + + + +Internet Architecture Board [Page 17] + +RFC 1410 IAB Standards March 1993 + + + 1396 - The Process for Organization of Internet Standards Working + Group (POISED), Steve Crocker, Chair + + This is an information document and does not specify any + level of standard. + + 1395 - BOOTP Vendor Information Extensions + + This is a status report. + + 1394 - Relationship of Telex Answerback Codes to Internet Domains + + This is an information document and does not specify any + level of standard. + + 1393 - Traceroute Using an IP Option + + An Experimental protocol. + + 1392 - Internet Users' Glossary + + This is an information document and does not specify any + level of standard. + + 1391 - The Tao of IETF - A Guide for New Attendees of the Internet + Engineering Task Force + + This is an information document and does not specify any + level of standard. + + 1390 - Transmission of IP and ARP over FDDI Networks + + A full Standard protocol. + + 1389 - RIP Version 2 MIB Extension + + A Proposed Standard protocol. + + 1388 - RIP Version 2 - Carrying Additional Information + + A Proposed Standard protocol. + + 1387 - RIP Version 2 Protocol Analysis + + This is an information document and does not specify any + level of standard. + + + + + +Internet Architecture Board [Page 18] + +RFC 1410 IAB Standards March 1993 + + + 1386 - The US Domain + + This is an information document and does not specify any + level of standard. + + 1385 - EIP: The Extended Internet Protocol A Framework for + Maintaining Backward Compatibility + + This is an information document and does not specify any + level of standard. + + 1384 - Naming Guidelines for Directory Pilots + + This is an information document and does not specify any + level of standard. + + 1383 - An Experiment in DNS Based IP Routing + + An Experimental protocol. + + 1382 - SNMP MIB Extension for the X.25 Packet Layer + + A Proposed Standard protocol. + + 1381 - SNMP MIB Extension for X.25 LAPB + + A Proposed Standard protocol. + + 1380 - IESG Deliberations on Routing and Addressing + + This is an information document and does not specify any + level of standard. + + 1379 - Extending TCP for Transactions -- Concepts + + This is an information document and does not specify any + level of standard. + + 1378 - The PPP AppleTalk Control Protocol (ATCP) + + A Proposed Standard protocol. + + 1377 - The PPP OSI Network Layer Control Protocol (OSINLCP) + + A Proposed Standard protocol. + + + + + + +Internet Architecture Board [Page 19] + +RFC 1410 IAB Standards March 1993 + + + 1376 - The PPP DECnet Phase IV Control Protocol (DNCP) + + A Proposed Standard protocol. + + 1375 - Suggestion for New Classes of IP Addresses + + This is an information document and does not specify any + level of standard. + + 1374 - IP and ARP on HIPPI + + A Proposed Standard protocol. + + 1373 - PORTABLE DUAs + + This is an information document and does not specify any + level of standard. + + 1372 - Telnet Remote Flow Control Option + + A Proposed Standard protocol. + + 1371 - Choosing a "Common IGP" for the IP Internet (The IESG's + Recommendation to the IAB) + + This is an information document and does not specify any + level of standard. + + 1370 - Applicability Statement for OSPF + + A Proposed Standard protocol. + + 1369 - Implementation Notes and Experience for The Internet + Ethernet MIB + + This is an information document and does not specify any + level of standard. + + 1368 - Definitions of Managed Objects for IEEE 802.3 Repeater + Devices + + A Proposed Standard protocol. + + 1367 - Schedule for IP Address Space Management Guidelines + + This is an information document and does not specify any + level of standard. + + + + +Internet Architecture Board [Page 20] + +RFC 1410 IAB Standards March 1993 + + + 1366 - Guidelines for Management of IP Address Space + + This is an information document and does not specify any + level of standard. + + 1365 - An IP Address Extension Proposal + + This is an information document and does not specify any + level of standard. + + 1364 - BGP OSPF Interaction + + A Proposed Standard protocol. + + 1363 - A Proposed Flow Specification + + This is an information document and does not specify any + level of standard. + + 1362 - Novell IPX Over Various WAN Media (IPXWAN) + + This is an information document and does not specify any + level of standard. + + 1334 - PPP Authentication Protocols + + A Proposed Standard protocol. + +6.1.2. Other Changes: + + The following are changes to protocols listed in the previous + edition. + + 1305 - Network Time Protocol (Version 3) Specification, + Implementation and Analysis + + Elevated to Draft Standard. + + 1230 - IEEE 802.4 Token Bus MIB + + Moved to Historic. + + 1212 - Concise MIB Definitions + + Elevated to full Standard. + + + + + + +Internet Architecture Board [Page 21] + +RFC 1410 IAB Standards March 1993 + + + 1191 - Path MTU Discovery + + Elevated to Draft Standard. + + 1189 - The Common Management Information Services and Protocols + for the Internet (CMOT and CMIP) + + Moved to Historic. + +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 +NTPV2 Network Time Protocol (Version 2) 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 +Concise-MIB Concise MIB Definitions Rec 1212 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 + + + +Internet Architecture Board [Page 22] + +RFC 1410 IAB Standards March 1993 + + +TFTP Trivial File Transfer Protocol Ele 1350 33 +RIP Routing Information Protocol Ele 1058 34 +TP-TCP ISO Transport Service on top of the TCP Ele 1006 35 * + +[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 + 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). + + 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". + + + + + +Internet Architecture Board [Page 23] + +RFC 1410 IAB Standards March 1993 + + +6.3. Network-Specific Standard Protocols + +All Network-Specific Standards have Elective status. + +Protocol Name State RFC STD * +======== ===================================== ===== ===== === = +IP-FDDI Transmission of IP and ARP over FDDI Net Std 1390 36 * +IP-HIPPI IP and ARP on HIPPI Prop 1374 * +IP-X.25 X.25 and ISDN in the Packet Mode Prop 1356 +IP-FR Multiprotocol over Frame Relay Prop 1294 +IP-SMDS IP Datagrams over the SMDS Service Prop 1209 +IP-ARCNET Transmitting IP Traffic over ARCNET Nets Prop 1201 +ARP Address Resolution Protocol Std 826 37 +RARP A Reverse Address Resolution Protocol Std 903 38 +IP-ARPA Internet Protocol on ARPANET Std BBN1822 +IP-WB Internet Protocol on Wideband Network Std 907 +IP-E Internet Protocol on Ethernet Networks Std 894 +IP-EE Internet Protocol on Exp. Ethernet Nets Std 895 +IP-IEEE Internet Protocol on IEEE 802 Std 1042 +IP-DC Internet Protocol on DC Networks Std 891 +IP-HC Internet Protocol on Hyperchannel Std 1044 +IP-ARC Internet Protocol on ARCNET Std 1051 +IP-SLIP Transmission of IP over Serial Lines Std 1055 +IP-NETBIOS Transmission of IP over NETBIOS Std 1088 +IP-IPX Transmission of 802.2 over IPX Networks Std 1132 + +[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 + also the Host and Gateway Requirements RFCs for more specific + information on network-specific ("link layer") protocols. + + + + + + + + + + + + +Internet Architecture Board [Page 24] + +RFC 1410 IAB Standards March 1993 + + +6.4. Draft Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +ETHER-MIB Ethernet MIB Elective 1398* +NTPV3 Network Time Protocol (Version 3) Elective 1305* +IP-MTU Path MTU Discovery Elective 1191* +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 +IP-FDDI Internet Protocol on FDDI Networks Elective 1188 +PPP Point to Point Protocol Elective 1171 +BOOTP Bootstrap Protocol Recommended 951,1395* +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: + + 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 + in the future. + +6.5. Proposed Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +SMTP-SIZE SMTP Service Ext for Message Size Elective 1427* +SMTP-8BIT SMTP Service Ext or 8bit-MIMEtransport Elective 1426* +SMTP-EXT SMTP Service Extensions Elective 1425* +PEM-KEY PEM - Key Certification Elective 1424* +PEM-ALG PEM - Algorithms, Modes, and Identifiers Elective 1423* +PEM-CKM PEM - Certificate-Based Key Management Elective 1422* +PEM-ENC PEM - Message Encryption and Auth Elective 1421* +SNMP-IPX SNMP over IPX Elective 1420* +SNMP-AT SNMP over AppleTalk Elective 1419* +SNMP-OSI SNMP over OSI Elective 1418* +FTP-FTAM FTP-FTAM Gateway Specification Elective 1415* +IDENT-MIB Identification MIB Elective 1414* +IDENT Identification MIB Elective 1413* +DS3/E3-MIB DS3/E3 Interface Type Elective 1407* +DS1/E1-MIB DS1/E1 Interface Type Elective 1406* +BGP-OSPF BGP OSPF Interaction Elective 1403* +-------- Route Advertisement In BGP2 And BGP3 Elective 1397* +RIP2-MIB RIP Version 2 MIB Extension Elective 1389* + + + +Internet Architecture Board [Page 25] + +RFC 1410 IAB Standards March 1993 + + +RIP2 RIP Version 2-Carrying Additional Info. Elective 1388* +SNMP-X.25 SNMP MIB Extension for X.25 Packet Layer Elective 1382* +SNMP-LAPB SNMP MIB Extension for X.25 LAPB Elective 1381* +PPP-ATCP PPP AppleTalk Control Protocol Elective 1378* +PPP-OSINLCP PPP OSI Network Layer Control Protocol Elective 1377* +PP-DNCP PPP DECnet Phase IV Control Protocol Elective 1376* +802.3-MIB IEEE 802.3 Repeater MIB Elective 1368* +BGP-OSPF BGP OSPF Interaction Elective 1364* +TABLE-MIB IP Forwarding Table MIB Elective 1354 +SNMP-PARTY-MIB 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-AUTH PPP Authentication Elective 1334* +PPP-LINK PPP Link Quality Monitoring Elective 1333 +PPP-IPCP PPP Control Protocol Elective 1332 +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 + + + +Internet Architecture Board [Page 26] + +RFC 1410 IAB Standards March 1993 + + +802.5-MIB IEEE 802.5 Token Ring MIB Elective 1231 +GINT-MIB Extensions to the Generic-Interface MIB Elective 1229 +PPP-EXT PPP Extensions for Bridging Elective 1220 +OIM-MIB-II OSI Internet Management: MIB-II Elective 1214 +IS-IS OSI IS-IS for TCP/IP Dual Environments Elective 1195 +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 +------- Mapping Between X.400(1984) Elective 1026,987 +NNTP Network News Transfer Protocol Elective 977 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +Applicability Statements: + + OSPF - RFC 1370 is an applicability statement for OSPF. + +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 +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 736 + + + +Internet Architecture Board [Page 27] + +RFC 1410 IAB Standards March 1993 + + +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 1372* +TOPT-LINE Linemode 34 Draft Ele 1184 +TOPT-XDL X Display Location 35 Prop Ele 1096 +TOPT-ENVIR Telnet Environment Option 36 Prop Ele 1408* +TOPT-AUTH Telnet Authentication Option 37 Exp Ele 1416* +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 + +All Experimental protocols have the Limited Use status. + +Protocol Name RFC +======== ===================================== ===== +DIR-ARP Directed ARP 1433* +TEL-SPX Telnet Authentication: SPX 1412* +TEL-KER Telnet Authentication: Kerberos V4 1411* +MAP-MAIL X.400 Mapping and Mail-11 1405* +TRACE-IP Traceroute Using an IP Option 1393* +DNS-IP Experiment in DNS Based IP Routing 1383* +DNS NSAP DNS NSAP RRs 1348 +RMCP Remote Mail Checking Protocol 1339 +MSP2 Message Send Protocol 2 1312 +DSLCP Dynamically Switched Link Control 1307 +-------- X.500 and Domains 1279 +SNMP-OSI SNMP over OSI 1283 +IN-ENCAP Internet Encapsulation Protocol 1241 +CLNS-MIB CLNS-MIB 1238 +CFDP Coherent File Distribution Protocol 1235 +SNMP-DPI SNMP Distributed Program Interface 1228 +SNMP-MUX SNMP MUX Protocol and MIB 1227 +IP-AX.25 IP Encapsulation of AX.25 Frames 1226 +ALERTS Managing Asynchronously Generated Alerts 1224 +MPP Message Posting Protocol 1204 +ST-II Stream Protocol 1190 + + + +Internet Architecture Board [Page 28] + +RFC 1410 IAB Standards March 1993 + + +SNMP-BULK Bulk Table Retrieval with the SNMP 1187 +DNS-RR New DNS RR Definitions 1183 +NTP-OSI NTP over OSI Remote Operations 1165 +EHF-MAIL Encoding Header Field for Mail 1154 +DMF-MAIL Digest Message Format for Mail 1153 +RDP Reliable Data Protocol 908,1151 +-------- Mapping between X.400(88) and RFC-822 1148 +TCP-ACO TCP Alternate Checksum Option 1146 +-------- Mapping full 822 to Restricted 822 1137 +IP-DVMRP IP Distance Vector Multicast Routing 1075 +TCP-LDP TCP Extensions for Long Delay Paths 1072 +IMAP2 Interactive Mail Access Protocol 1176,1064 +IMAP3 Interactive Mail Access Protocol 1203 +VMTP Versatile Message Transaction Protocol 1045 +COOKIE-JAR Authentication Scheme 1004 +NETBLT Bulk Data Transfer Protocol 998 +IRTP Internet Reliable Transaction Protocol 938 +AUTH Authentication Service 931 +LDP Loader Debugger Protocol 909 +RLP Resource Location Protocol 887 +NVP-II Network Voice Protocol ISI-memo +PVP Packet Video Protocol 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 + +Information protocols have no status. + +Protocol Name RFC +======= ==================================== ===== +GOPHER The Internet Gopher Protocol 1436* +------- Data Link Switching: Switch-to-Switch Protocol 1434* +LISTSERV Listserv Distribute Protocol 1429* +------- Replication Requirements 1275 +PCMAIL Pcmail Transport Protocol 1056 +MTP Multicast Transport Protocol 1301 +SNMP-IPX SNMP over IPX 1298 +BSD Login BSD Login 1282 +DIXIE DIXIE Protocol Specification 1249 +IP-X.121 IP to X.121 Address Mapping for DDN 1236 +OSI-HYPER OSI and LLC1 on HYPERchannel 1223 +HAP2 Host Access Protocol 1221 +SUBNETASGN On the Assignment of Subnet Numbers 1219 +SNMP-TRAPS Defining Traps for use with SNMP 1215 +DAS Directory Assistance Service 1202 +MD4 MD4 Message Digest Algorithm 1186 + + + +Internet Architecture Board [Page 29] + +RFC 1410 IAB Standards March 1993 + + +LPDP Line Printer Daemon Protocol 1179 + +[Note: an asterisk at the end of a line indicates a change from the +previous edition of this document.] + +6.9. Historic Protocols + +All Historic protocols have Not Recommended status. + +Protocol Name RFC +======= ===================================== ===== +802.4-MIP IEEE 802.4 Token Bus MIB 1230* +CMOT Common Management Information Services 1189* +PPP-INIT PPP Initial Configuration Options 1172 +MSP Message Send Protocol 1159 +-------- Mail Privacy: Procedures 1113 +-------- Mail Privacy: Key Management 1114 +-------- Mail Privacy: Algorithms 1115 +NFILE A File Access Protocol 1037 +HOSTNAME HOSTNAME Protocol 953 +SFTP Simple File Transfer Protocol 913 +SUPDUP SUPDUP Protocol 734 +BGP Border Gateway Protocol 1163,1164 +MIB-I MIB-I 1156 +SGMP Simple Gateway Monitoring Protocol 1028 +HEMS High Level Entity Management Protocol 1021 +STATSRV Statistics Server 996 +POP2 Post Office Protocol, Version 2 937 +RATP Reliable Asynchronous Transfer Protocol 916 +HFEP Host - Front End Protocol 929 +THINWIRE Thinwire Protocol 914 +HMP Host Monitoring Protocol 869 +GGP Gateway Gateway Protocol 823 +RTELNET Remote Telnet Service 818 +CLOCK DCNET Time Server Protocol 778 +MPM Internet Message Protocol 759 +NETRJS Remote Job Service 740 +NETED Network Standard Text Editor 569 +RJE Remote Job Entry 407 +XNET Cross Net Debugger IEN-158 +NAMESERVER Host Name Server Protocol IEN-116 +MUX Multiplexing Protocol IEN-90 +GRAPHICS Graphics Protocol 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 30] + +RFC 1410 IAB Standards March 1993 + + +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@ANS.NET + + + + + +Internet Architecture Board [Page 31] + +RFC 1410 IAB Standards March 1993 + + + Greg Vaudreuil + IESG Secretary + Corporation for National Research Initiatives + 1895 Preston White Drive, Suite 100 + Reston, VA 22091 + + 1-703-620-8990 + + gvaudre@CNRI.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@CNRI.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 32] + +RFC 1410 IAB Standards March 1993 + + +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 33] + +RFC 1410 IAB Standards March 1993 + + +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 34] + +RFC 1410 IAB Standards March 1993 + + +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 35] + \ No newline at end of file -- cgit v1.2.3