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/rfc1250.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc1250.txt (limited to 'doc/rfc/rfc1250.txt') diff --git a/doc/rfc/rfc1250.txt b/doc/rfc/rfc1250.txt new file mode 100644 index 0000000..deddbbe --- /dev/null +++ b/doc/rfc/rfc1250.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group Internet Activities Board +Request for Comments: 1250 J. Postel, Editor +Obsoletes: RFCs 1200, August 1991 +1100, 1083, 1130, 1140 + + + + IAB OFFICIAL PROTOCOL STANDARDS + + +Status of this Memo + + This memo describes the state of standardization of protocols used in + the Internet as determined by the Internet Activities Board (IAB). + 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. Annotated Internet Protocols . . . . . . . . . . . . . . . 6 + 3.3. Gateway Requirements . . . . . . . . . . . . . . . . . . . 6 + 3.4. Host Requirements . . . . . . . . . . . . . . . . . . . . 6 + 3.5. The MIL-STD Documents . . . . . . . . . . . . . . . . . . 6 + 4. Explanation of Terms . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Definitions of Protocol State . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . .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 . . . . . . . . . . . . . . . . . . . . 17 + + + +Internet Activities Board [Page 1] + +RFC 1250 IAB Standards August 1991 + + + 6.2. Standard Protocols . . . . . . . . . . . . . . . . . . . 18 + 6.3. Network-Specific Standard Protocols . . . . . . . . . . 19 + 6.4. Draft Standard Protocols . . . . . . . . . . . . . . . . 20 + 6.5. Proposed Standard Protocols . . . . . . . . . . . . . . 21 + 6.6. Telnet Options . . . . . . . . . . . . . . . . . . . . . 22 + 6.7. Experimental Protocols . . . . . . . . . . . . . . . . . 23 + 6.8. Informational Protocols . . . . . . . . . . . . . . . . 23 + 6.9. Historic Protocols . . . . . . . . . . . . . . . . . . . 24 + 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.1. IAB, IETF, and IRTF Contacts . . . . . . . . . . . . . . 24 + 7.1.1. Internet Activities Board (IAB) Contact . . . . . . . 24 + 7.1.2. Internet Engineering Task Force (IETF) Contact . . . . 25 + 7.1.3. Internet Research Task Force (IRTF) Contact . . . . . 25 + 7.2. Internet Assigned Numbers Authority (IANA) Contact . . . 26 + 7.3. Request for Comments Editor Contact . . . . . . . . . . 27 + 7.4. Network Information Center Contact . . . . . . . . . . . 27 + 7.5. Other Sources for Requests for Comments . . . . . . . . 28 + 8. Security Considerations . . . . . . . . . . . . . . . . . 28 + 9. Author's Address . . . . . . . . . . . . . . . . . . . . . 28 + +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 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 30-Nov-91. + + 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. + +1. The Standardization Process + + The Internet Activities Board maintains this list of documents that + define standards for the Internet protocol suite (see 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)). 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 + + + +Internet Activities Board [Page 2] + +RFC 1250 IAB Standards August 1991 + + + the Internet protocols are increasingly in general commercial use. + + 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 (proposed standard, draft standard, and standard) + involving increasing amounts of scrutiny and experimental testing. + 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 4 + months before a proposed standard can be advanced to a draft standard + and 6 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 + 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. + + + +Internet Activities Board [Page 3] + +RFC 1250 IAB Standards August 1991 + + + 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 + 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 + + + +Internet Activities Board [Page 4] + +RFC 1250 IAB Standards August 1991 + + + 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). + + 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 + 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. + + + + +Internet Activities Board [Page 5] + +RFC 1250 IAB Standards August 1991 + + +3. Other Reference Documents + + There are four other reference documents of interest in checking the + current status of protocol specifications and standardization. These + are the Assigned Numbers, the Annotated Internet Protocols, the + Gateway Requirements, and the Host Requirements. Note that these + documents are revised and updated at different times; in case of + differences between these documents, the most recent must prevail. + + Also, one should be aware of the MIL-STD publications on IP, TCP, + Telnet, FTP, and SMTP. These are described in Section 3.5. + +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-1060. + + 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. Annotated Internet Protocols + + This document lists the protocols and describes any known problems + and ongoing experiments. This document was most recently issued as + RFC-1011. + +3.3. 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.4. 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.5. The MIL-STD Documents + + The Internet community specifications for IP (RFC-791) and TCP (RFC- + 793) and the DoD MIL-STD specifications are intended to describe + exactly the same protocols. Any difference in the protocols + specified by these sets of documents should be reported to DCA and to + + + +Internet Activities Board [Page 6] + +RFC 1250 IAB Standards August 1991 + + + 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. These five documents are included in the 1985 DDN Protocol + Handbook (available from the Network Information Center, see Section + 7.4). + + 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 STATE of standardization, one of "standard", "draft standard", + "proposed standard", "experimental", "informational" or "historic". + The second is the STATUS (requirement level or applicability) 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, + + + +Internet Activities Board [Page 7] + +RFC 1250 IAB Standards August 1991 + + + 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 + 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 | X | | + A +-----+-----+-----+-----+-----+ + Info | | X | XXX | X | X | + T +-----+-----+-----+-----+-----+ + Expr | | | X | XXX | X | + 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 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 are separated into two groups: (1) IP + protocol and above, protocols that apply to the whole Internet; + and (2) network-specific protocols, generally specifications of + how to do IP on particular types of networks. + + + + +Internet Activities Board [Page 8] + +RFC 1250 IAB Standards August 1991 + + + 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 Activities Board [Page 9] + +RFC 1250 IAB Standards August 1991 + + +4.2. Definitions of Protocol Status + + This document lists a STATUS (requirement level or applicability) + 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 Activities Board [Page 10] + +RFC 1250 IAB Standards August 1991 + + + +==========================================================+ + |**************| S O U R C E | + +==========================================================+ + | Desired | IAB | IESG | IRSG | Other | + | Status | | | or RG | | + +==========================================================+ + | | | | | | + | 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 Activities Board [Page 11] + +RFC 1250 IAB Standards August 1991 + + + 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 four months for proposed standard, minimum + six 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 Activities Board [Page 12] + +RFC 1250 IAB Standards August 1991 + + + | + +<----------------------------------------------+ + | ^ + 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 + four 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 six 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 Activities Board [Page 13] + +RFC 1250 IAB Standards August 1991 + + +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: + + 1252 - OSPF Version 2 MIB + + A Proposed Standard protocol. + + 1251 - Who's Who in the Internet + + This is an information document and does not specify any + level of standard. + + 1250 - This memo. + + 1249 - DIXIE Protocol Specification + + This is an information document and does not specify any + level of standard. + + 1248 - OSPF Version 2 MIB + + A Proposed Standard protocol. + + 1247 - OSPF Version 2 + + A Draft Standard protocol. + + 1246 - Experience with the OSPF Protocol + + This is an information document and does not specify any + level of standard. + + 1245 - OSPF Protocol Analysis + + This is an information document and does not specify any + level of standard. + + 1244 - Site Security Handbook + + This is an information document and does not specify any + level of standard. + + + + +Internet Activities Board [Page 14] + +RFC 1250 IAB Standards August 1991 + + + 1243 - AppleTalk Management Information Base + + A Proposed Standard protocol. + + 1242 - Benchmarking Terminology for Network Interconnection + Devices + + This is an information document and does not specify any + level of standard. + + 1241 - A Scheme for an Internet Encapsulation Protocol: Version 1 + + This is a new Experimental protocol. + + 1240 - OSI Connectionless Transport Services + on top of UDP - Version: 1 + + A Proposed Standard protocol. + + 1239 - Reassignment of Experimental MIBs to Standard MIBs + + A Proposed Standard protocol. + + 1238 - CLNS MIB - for use with Connectionless Network + Protocol (ISO 8473) and End System to Intermediate + System (ISO 9542) + + This is a new Experimental protocol. + + 1237 - Guidelines for OSI NSAP Allocation in the Internet + + A Proposed Standard protocol. + + 1236 - IP to X.121 Address Mapping for DDN + + This is an information document and does not specify any + level of standard. + + 1235 - The Coherent File Distribution Protocol + + This is a new Experimental protocol. + + 1234 - Tunneling IPX Traffic through IP Networks + + A Proposed Standard protocol. + + + + + + +Internet Activities Board [Page 15] + +RFC 1250 IAB Standards August 1991 + + + 1233 - Definitions of Managed Objects for the DS3 Interface Type + + A Proposed Standard protocol. + + 1232 - Definitions of Managed Objects for the DS1 Interface Type + + A Proposed Standard protocol. + + 1231 - IEEE 802.5 Token Ring MIB + + A Proposed Standard protocol. + + 1230 - IEEE 802.4 Token Bus MIB + + A Proposed Standard protocol. + + 1229 - Extensions to the Generic-Interface MIB + + A Proposed Standard protocol. + + 1228 - SNMP-DPI - Simple Network Management Protocol Distributed + Program Interface + + This is a new Experimental protocol. + + 1227 - SNMP MUX Protocol and MIB + + This is a new Experimental protocol. + + 1226 - Internet Protocol Encapsulation of AX.25 Frames + + This is a new Experimental protocol. + + 1225 - Post Office Protocol - Version 3 + + A Draft Standard protocol. + + 1224 - Techniques for Managing Asynchronously Generated Alerts + + This is a new Experimental protocol. + + 1223 - OSI CLNS and LLC1 Protocols on Network Systems HYPERchannel + + This is an information document and does not specify any + level of standard. + + + + + + +Internet Activities Board [Page 16] + +RFC 1250 IAB Standards August 1991 + + + 1222 - Advancing the NSFNET Routing Architecture + + This is an information document and does not specify any + level of standard. + + 1221 - Host Access Protocol (HAP) Specification - Version 2 + + This is an information document and does not specify any + level of standard. + + 1220 - Point-to-Point Protocol Extensions for Bridging + + A Proposed Standard protocol. + + 1219 - On the Assignment of Subnet Numbers + + This is an information document and does not specify any + level of standard. + + +6.1.2. Other Changes: + + The following are changes to protocols listed in the previous + edition. + + 1213 - Management Information Base for Network Management + of TCP/IP-based internets: MIB-II + + Advanced to Standard protocol. + + 1212 - Concise MIB Definitions + + Advanced to Draft Standard protocol. + + Section 6.6 on Telnet Options has been added. + + + + + + + + + + + + + + + + +Internet Activities Board [Page 17] + +RFC 1250 IAB Standards August 1991 + + +6.2. Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============= ===== +-------- Assigned Numbers Required 1060 +-------- Gateway Requirements Required 1009 +-------- Host Requirements - Communications Required 1122 +-------- Host Requirements - Applications Required 1123 +IP Internet Protocol Required 791 + as amended by: +-------- IP Subnet Extension Required 950 +-------- IP Broadcast Datagrams Required 919 +-------- IP Broadcast Datagrams with Subnets Required 922 +ICMP Internet Control Message Protocol Required 792 +IGMP Internet Group Multicast Protocol Recommended 1112 +UDP User Datagram Protocol Recommended 768 +TCP Transmission Control Protocol Recommended 793 +SMI Structure of Management Information Recommended 1155 +MIB-I Management Information Base Recommended 1156 +MIB-II Management Information Base-II Recommended 1213* +SNMP Simple Network Management Protocol Recommended 1157 +DOMAIN Domain Name System Recommended 1034,1035 +TELNET Telnet Protocol Recommended 854 +FTP File Transfer Protocol Recommended 959 +SMTP Simple Mail Transfer Protocol Recommended 821 +MAIL Format of Electronic Mail Messages Recommended 822 +DNS-MX Mail Routing and the Domain System Recommended 974 +CONTENT Content Type Header Field Recommended 1049 +EGP Exterior Gateway Protocol Recommended 904 +ECHO Echo Protocol Recommended 862 +NTP Network Time Protocol Recommended 1119 +NETBIOS NetBIOS Service Protocols Elective 1001,1002 +DISCARD Discard Protocol Elective 863 +CHARGEN Character Generator Protocol Elective 864 +QUOTE Quote of the Day Protocol Elective 865 +USERS Active Users Protocol Elective 866 +DAYTIME Daytime Protocol Elective 867 +TIME Time Server Protocol Elective 868 + +Applicability Statements: + + IGMP -- The Internet Activities 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 + + + +Internet Activities Board [Page 18] + +RFC 1250 IAB Standards August 1991 + + + 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-I, MIB-II SNMP -- The Internet Activities Board recommends + that all IP and TCP implementations be network manageable. At the + current time, this implies implementation of the Internet MIB-I + (RFC-1156), the extensions in MIB-II (RFC-1213), and at least the + recommended management protocol SNMP (RFC-1157). + +6.3. Network-Specific Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +ARP Address Resolution Protocol Elective 826 +RARP A Reverse Address Resolution Protocol Elective 903 +IP-ARPA Internet Protocol on ARPANET Elective BBN 1822 +IP-WB Internet Protocol on Wideband Network Elective 907 +IP-X25 Internet Protocol on X.25 Networks Elective 877 +IP-E Internet Protocol on Ethernet Networks Elective 894 +IP-EE Internet Protocol on Exp. Ethernet Nets Elective 895 +IP-IEEE Internet Protocol on IEEE 802 Elective 1042 +IP-DC Internet Protocol on DC Networks Elective 891 +IP-HC Internet Protocol on Hyperchannel Elective 1044 +IP-ARC Internet Protocol on ARCNET Elective 1051 +IP-SLIP Transmission of IP over Serial Lines Elective 1055 +IP-NETBIOS Transmission of IP over NETBIOS Elective 1088 +IP-FDDI Transmission of IP over FDDI Elective 1188 +IP-IPX Transmission of 802.2 over IPX Networks Elective 1132 + +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 Activities Board [Page 19] + +RFC 1250 IAB Standards August 1991 + + +6.4. Draft Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +OSPF2 Open Shortest Path First Routing V2 Elective 1247* +POP3 Post Office Protocol, Version 3 Elective 1225* +Concise-MIB Concise MIB Definitions Elective 1212* +FINGER Finger Protocol Elective 1196 +IP-FDDI Internet Protocol on FDDI Networks Elective 1188 +TOPT-LINE Telnet Linemode Option Elective 1184 +PPP Point to Point Protocol Elective 1171 +-------- Mail Privacy: Procedures Elective 1113 +-------- Mail Privacy: Key Management Elective 1114 +-------- Mail Privacy: Algorithms Elective 1115 +BOOTP Bootstrap Protocol Recommended 951,1084 +RIP Routing Information Protocol Elective 1058 +TP-TCP ISO Transport Service on top of the TCP Elective 1006 +NICNAME WhoIs Protocol Elective 954 +TFTP Trivial File Transfer Protocol Elective 783 + +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-specific standard protocol state + in the future. + + + + +Internet Activities Board [Page 20] + +RFC 1250 IAB Standards August 1991 + + +6.5. Proposed Standard Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +OSPF-MIB OSPF Version 2 MIB Elective 1248,1252* +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* +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 + and Protocol over TCP/IP +PPP-INIT PPP Initial Configuration Options Elective 1172 +BGP Border Gateway Protocol Elective 1163,1164 +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 +PCMAIL Pcmail Transport Protocol Elective 1056 +NFILE A File Access Protocol Elective 1037 +------- Mapping between X.400(84) and RFC-822 Elective 987,1026 +NNTP Network News Transfer Protocol Elective 977 +HOSTNAME HOSTNAME Protocol Elective 953 +SFTP Simple File Transfer Protocol Elective 913 +RLP Resource Location Protocol Elective 887 +SUPDUP SUPDUP Protocol Elective 734 + +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. + + + + + + + +Internet Activities Board [Page 21] + +RFC 1250 IAB Standards August 1991 + + +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 +======== ===================================== ============== ===== +TOPT-BIN Binary Transmission 0 Std Rec 856* +TOPT-ECHO Echo 1 Std Rec 857* +TOPT-RECN Reconnection 2 Prop Ele ...* +TOPT-SUPP Suppress Go Ahead 3 Std Rec 858* +TOPT-APRX Approx Message Size Negotiation 4 Prop Ele ...* +TOPT-STAT Status 5 Std Rec 859* +TOPT-TIM Timing Mark 6 Std Rec 860* +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 734* +TOPT-SUPO SUPDUP Output 22 Prop Ele 749* +TOPT-SNDL Send Location 23 Prop Ele 779* +TOPT-TERM Terminal Type 24 Prop Ele 930* +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* + + + + + + + +Internet Activities Board [Page 22] + +RFC 1250 IAB Standards August 1991 + + +6.7. Experimental Protocols + +Protocol Name Status RFC +======== ===================================== ============== ===== +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 +MSP Message Send Protocol Limited Use 1159 +EHF-MAIL Encoding Header Field for Mail Elective 1154 +DMF-MAIL Digest Message Format for Mail Elective 1153 +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 + + +6.8. Informational Protocols + +Protocol Name Status RFC +======= ==================================== =============== ===== +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 + + + +Internet Activities Board [Page 23] + +RFC 1250 IAB Standards August 1991 + + +MD4 MD4 Message Digest Algorithm Limited Use 1186 +LPDP Line Printer Daemon Protocol Limited Use 1179 + +6.9. Historic Protocols + +Protocol Name Status RFC +======= ===================================== ============== ===== +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 + +7. Contacts + +7.1. IAB, IETF, and IRTF Contacts + + 7.1.1. Internet Activities Board (IAB) Contact + + Please send your comments about this list of protocols and especially + about the Draft Standard Protocols to the Internet Activities 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-213-822-1511 + + Braden@ISI.EDU + + + +Internet Activities Board [Page 24] + +RFC 1250 IAB Standards August 1991 + + + Vinton G. Cerf + Chair of the IAB + Corporation for National Research Initiatives + 1895 Preston White Drive, Suite 100 + Reston, VA 22091 + + 1-703-620-8990 + + VCerf@NRI.RESTON.VA.US + + 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 + + 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 + + 7.1.3. Internet Research Task Force (IRTF) Contact + + Contact: + + David D. Clark + Chair of the IRTF + Massachusetts Institute of Technology + Laboratory for Computer Science + 545 Main Street + Cambridge, MA 02139 + + 1-617-253-6003 + + ddc@LCS.MIT.EDU + + + +Internet Activities Board [Page 25] + +RFC 1250 IAB Standards August 1991 + + +7.2. Internet Assigned Numbers Authority Contact + + Contact: + + Joyce K. Reynolds + Internet Assigned Numbers Authority + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + 1-213-822-1511 + + IANA@ISI.EDU + + The protocol standards are managed for the IAB by the Internet + Assigned Numbers Authority. + + Please refer to the documents "Assigned Numbers" (RFC-1060) and + "Official Internet Protocols" (RFC-1011) for further information + about the status of protocol documents. There are two documents that + summarize the requirements for host and gateways in the Internet, + "Host Requirements" (RFC-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 Activities Board [Page 26] + +RFC 1250 IAB Standards August 1991 + + +7.3. Request for Comments Editor Contact + + Contact: + + Jon Postel + RFC Editor + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + 1-213-822-1511 + + Postel@ISI.EDU + + Documents may be submitted via electronic mail to the RFC Editor for + consideration for publication as RFC. If you are not familiar with + the format or style requirements please request the "Instructions for + RFC Authors". In general, the style of any recent RFC may be used as + a guide. + +7.4. The Network Information Center and + Requests for Comments Distribution Contact + + Contact: + + DDN Network Information Center + SRI International + Room EJ291 + 333 Ravenswood Avenue + Menlo Park, CA 94025 + + 1-800-235-3155 + 1-415-859-3695 + + 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. + + RFCs can be obtained via FTP from NISC.SRI.COM, with the pathname + "rfc/rfcnnnn.txt" where "nnnn" refers to the number of the RFC. A + list of all RFCs may be obtained by copying the file "rfc/rfc- + index.txt". Log in with FTP username "anonymous" and password + "guest". + + The NIC also provides an automatic mail service for those sites which + cannot use FTP. Address the request to MAIL-SERVER@NISC.SRI.COM and + + + +Internet Activities Board [Page 27] + +RFC 1250 IAB Standards August 1991 + + + in the body of the message indicate the file name, as in "send + rfc:rfcnnnn.txt". + + Some RFCs are now available in PostScript, these may be obtained from + the NIC in a similar fashion by substituting ".ps" for ".txt". + + How to obtain the most recent edition of this "IAB Official + Protocol Standards" memo: + + The file RFC:IAB-STANDARDS.TXT may be copied via FTP from the + NIC.DDN.MIL computer following the same procedures used to + obtain RFCs. + +7.5. Other Sources for Requests for Comments + + Information about other sources for RFCs and the procedures for + copying RFCs form those sources may be found in the file "in- + notes/rfc-retrieval.txt" on the host VENERA.ISI.EDU. + +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: 213-822-1511 + Fax: 213-823-6714 + + Email: Postel@ISI.EDU + + + + + + + + + + + + + + + + + +Internet Activities Board [Page 28] + \ No newline at end of file -- cgit v1.2.3