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/rfc901.txt | 1624 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1624 insertions(+) create mode 100644 doc/rfc/rfc901.txt (limited to 'doc/rfc/rfc901.txt') diff --git a/doc/rfc/rfc901.txt b/doc/rfc/rfc901.txt new file mode 100644 index 0000000..8e5f653 --- /dev/null +++ b/doc/rfc/rfc901.txt @@ -0,0 +1,1624 @@ + + +Network Working Group J. Reynolds +Request for Comments: 901 J. Postel + ISI +Obsoletes: RFCs 880, 840 June 1984 + + + OFFICIAL ARPA-INTERNET PROTOCOLS + + +Status of this Memo + + This memo is an official status report on the protocols used in the + ARPA-Internet community. + +Introduction + + This RFC identifies the documents specifying the official protocols + used in the Internet. Annotations identify any revisions or changes + planned. + + To first order, the official protocols are those in the "Internet + Protocol Transition Workbook" (IPTW) dated March 1982. There are + several protocols in use that are not in the IPTW. A few of the + protocols in the IPTW have been revised. Notably, the mail protocols + have been revised and issued as a volume titled "Internet Mail + Protocols" dated November 1982. Telnet and the most useful option + protocols were issued by the NIC in a booklet entitled "Internet + Telnet Protocol and Options" (ITP), dated June 1983. Some protocols + have not been revised for many years, these are found in the old + "ARPANET Protocol Handbook" (APH) dated January 1978. There is also + a volume of protocol related information called the "Internet + Protocol Implementers Guide" (IPIG) dated August 1982. + + This document is organized as a sketchy outline. The entries are + protocols (e.g., Transmission Control Protocol). In each entry there + are notes on status, specification, comments, other references, + dependencies, and contact. + + The status is one of: required, recommended, elective, or + experimental. + + The specification identifies the protocol defining documents. + + The comments describe any differences from the specification or + problems with the protocol. + + The other references identify documents that comment on or expand + on the protocol. + + The dependencies indicate what other protocols are called upon by + this protocol. + + + +Reynolds & Postel [Page 1] + + + +Official ARPA-Internet Protocols RFC 901 + + + The contact indicates a person who can answer questions about the + protocol. + + In particular, the status may be: + + required + + - all hosts must implement the required protocol, + + recommended + + - all hosts are encouraged to implement the recommended + protocol, + + elective + + - hosts may implement or not the elective protocol, + + experimental + + - hosts should not implement the experimental protocol + unless they are participating in the experiment and have + coordinated their use of this protocol with the contact + person, and + + none + + - this is not a protocol. + + For further information about protocols in general, please + contact: + + Joyce Reynolds + USC - Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, California 90292-6695 + + Phone: (213) 822-1511 + + ARPA mail: JKREYNOLDS@USC-ISIF.ARPA + + + + + + + + + + + +Reynolds & Postel [Page 2] + + + +Official ARPA-Internet Protocols RFC 901 + + +Overview + + Catenet Model ------------------------------------------------------ + + STATUS: None + + SPECIFICATION: IEN 48 (in IPTW) + + COMMENTS: + + Gives an overview of the organization and principles of the + Internet. + + Could be revised and expanded. + + OTHER REFERENCES: + + RFC 871 - A Perspective on the ARPANET Reference Model + + DEPENDENCIES: + + CONTACT: Postel@USC-ISIF.ARPA + +Network Level + + Internet Protocol (IP) --------------------------------------------- + + STATUS: Required + + SPECIFICATION: RFC 791 (in IPTW) + + COMMENTS: + + This is the universal protocol of the Internet. This datagram + protocol provides the universal addressing of hosts in the + Internet. + + A few minor problems have been noted in this document. + + The most serious is a bit of confusion in the route options. + The route options have a pointer that indicates which octet of + the route is the next to be used. The confusion is between the + phrases "the pointer is relative to this option" and "the + smallest legal value for the pointer is 4". If you are + confused, forget about the relative part, the pointer begins + at 4. + + Another important point is the alternate reassembly procedure + suggested in RFC 815. + + +Reynolds & Postel [Page 3] + + + +Official ARPA-Internet Protocols RFC 901 + + + Note that ICMP is defined to be an integral part of IP. You + have not completed an implementation of IP if it does not + include ICMP. + + OTHER REFERENCES: + + RFC 815 (in IPIG) - IP Datagram Reassembly Algorithms + + RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes + + RFC 816 (in IPIG) - Fault Isolation and Recovery + + RFC 817 (in IPIG) - Modularity and Efficiency in Protocol + Implementation + + MIL-STD-1777 - Military Standard Internet Protocol + + DEPENDENCIES: + + CONTACT: Postel@USC-ISIF.ARPA + + Internet Control Message Protocol (ICMP) --------------------------- + + STATUS: Required + + SPECIFICATION: RFC 792 (in IPTW) + + COMMENTS: + + The control messages and error reports that go with the + Internet Protocol. + + A few minor errors in the document have been noted. + Suggestions have been made for additional types of redirect + message and additional destination unreachable messages. + + Note that ICMP is defined to be an integral part of IP. You + have not completed an implementation of IP if it does not + include ICMP. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + +Reynolds & Postel [Page 4] + + + +Official ARPA-Internet Protocols RFC 901 + + +Host Level + + User Datagram Protocol (UDP) --------------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 768 (in IPTW) + + COMMENTS: + + Provides a datagram service to applications. Adds port + addressing to the IP services. + + The only change noted for the UDP specification is a minor + clarification that if in computing the checksum a padding octet + is used for the computation it is not transmitted or counted in + the length. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Transmission Control Protocol (TCP) -------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 793 (in IPTW) + + COMMENTS: + + Provides reliable end-to-end data stream service. + + Many comments and corrections have been received for the TCP + specification document. These are primarily document bugs + rather than protocol bugs. + + Event Processing Section: There are many minor corrections and + clarifications needed in this section. + + Push: There are still some phrases in the document that give a + "record mark" flavor to the push. These should be further + clarified. The push is not a record mark. + + Listening Servers: Several comments have been received on + difficulties with contacting listening servers. There should + be some discussion of implementation issues for servers, and + + + +Reynolds & Postel [Page 5] + + + +Official ARPA-Internet Protocols RFC 901 + + + some notes on alternative models of system and process + organization for servers. + + Maximum Segment Size: The maximum segment size option should + be generalized and clarified. It can be used to either + increase or decrease the maximum segment size from the default. + The TCP Maximum Segment Size is the IP Maximum Datagram Size + minus forty. The default IP Maximum Datagram Size if 576. The + default TCP Maximum Segement Size is 536. For further + discussion, see RFC 879. + + Idle Connections: There have been questions about + automatically closing idle connections. Idle connections are + ok, and should not be closed. There are several cases where + idle connections arise, for example, in Telnet when a user is + thinking for a long time following a message from the server + computer before his next input. There is no TCP "probe" + mechanism, and none is needed. + + Queued Receive Data on Closing: There are several points where + it is not clear from the description what to do about data + received by the TCP but not yet passed to the user, + particularly when the connection is being closed. In general, + the data is to be kept to give to the user if he does a RECV + call. + + Out of Order Segments: The description says that segments that + arrive out of order, that is, are not exactly the next segment + to be processed, may be kept on hand. It should also point out + that there is a very large performance penalty for not doing + so. + + User Time Out: This is the time out started on an open or send + call. If this user time out occurs the user should be + notified, but the connection should not be closed or the TCB + deleted. The user should explicitly ABORT the connection if he + wants to give up. + + OTHER REFERENCES: + + RFC 813 (in IPIG) - Window and Acknowledgement Strategy in TCP + + RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes + + RFC 816 (in IPIG) - Fault Isolation and Recovery + + RFC 817 (in IPIG) - Modularity and Efficiency in Protocol + Implementation + + + +Reynolds & Postel [Page 6] + + + +Official ARPA-Internet Protocols RFC 901 + + + RFC 879 - TCP Maximum Segment Size + + RFC 889 - Internet Delay Experiments + + RFC 896 - TCP/IP Congestion Control + + MIL-STD-1778 - Military Standard Transmission Control Protocol + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Host Monitoring Protocol (HMP) ------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 869 + + COMMENTS: + + This is a good tool for debugging protocol implementations in + remotely located computers. + + This protocol is used to monitor Internet gateways and the + TACs. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Hinden@BBN-UNIX.ARPA + + Cross Net Debugger (XNET) ------------------------------------------ + + STATUS: Elective + + SPECIFICATION: IEN 158 + + COMMENTS: + + A debugging protocol, allows debugger like access to remote + systems. + + This specification should be updated and reissued as an RFC. + + OTHER REFERENCES: + + RFC 643 + + + +Reynolds & Postel [Page 7] + + + +Official ARPA-Internet Protocols RFC 901 + + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + "Stub" Exterior Gateway Protocol ----------------------------------- + + STATUS: Recommended for Gateways + + SPECIFICATION: RFC 888 + + COMMENTS: + + The gateway protocol now under development. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: RFC 827, RFC 890 + + DEPENDENCIES: Internet Protocol + + CONTACT: Mills@USC-ISID.ARPA + + Gateway Gateway Protocol (GGP) ------------------------------------- + + STATUS: Experimental + + SPECIFICATION: RFC 823 + + COMMENTS: + + The gateway protocol now used in the core gateways. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Brescia@BBN-UNIX.ARPA + + + + + + + + + + +Reynolds & Postel [Page 8] + + + +Official ARPA-Internet Protocols RFC 901 + + + Multiplexing Protocol (MUX) ---------------------------------------- + + STATUS: Experimental + + SPECIFICATION: IEN 90 + + COMMENTS: + + Defines a capability to combine several segments from different + higher level protocols in one IP datagram. + + No current experiment in progress. There is some question as + to the extent to which the sharing this protocol envisions can + actually take place. Also, there are some issues about the + information captured in the multiplexing header being (a) + insufficient, or (b) over specific. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Stream Protocol (ST) ----------------------------------------------- + + STATUS: Experimental + + SPECIFICATION: IEN 119 + + COMMENTS: + + A gateway resource allocation protocol designed for use in + multihost real time applications. + + The implementation of this protocol has evolved and may no + longer be consistent with this specification. The document + should be updated and issued as an RFC. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol + + CONTACT: jwf@LL-EN.ARPA + + +Reynolds & Postel [Page 9] + + + +Official ARPA-Internet Protocols RFC 901 + + + Network Voice Protocol (NVP-II) ------------------------------------ + + STATUS: Experimental + + SPECIFICATION: RFC xxx + + COMMENTS: + + Defines the procedures for real time voice conferencing. + + The specification is an ISI Internal Memo which should be + updated and issued as an RFC. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Protocol, Stream Protocol + + CONTACT: Casner@USC-ISIB.ARPA + +Application Level + + Telnet Protocol (TELNET) ------------------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and + Options") + + COMMENTS: + + The protocol for remote terminal access. + + This has been revised since the IPTW. RFC 764 in IPTW is now + obsolete. + + OTHER REFERENCES: + + MIL-STD-1782 - Telnet Protocol and Options (TELNET) + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + +Reynolds & Postel [Page 10] + + + +Official ARPA-Internet Protocols RFC 901 + + + Telnet Options (TELNET-OPTIONS) ------------------------------------ + + STATUS: Elective + + SPECIFICATION: General description of options: RFC 855 + (in "Internet Telnet Protocol and Options") + + Number Name RFC NIC ITP APH USE + ------ --------------------------------- --- ----- --- --- --- + 0 Binary Transmission 856 ----- yes obs yes + 1 Echo 857 ----- yes obs yes + 2 Reconnection ... 15391 no yes no + 3 Suppress Go Ahead 858 ----- yes obs yes + 4 Approx Message Size Negotiation ... 15393 no yes no + 5 Status 859 ----- yes obs yes + 6 Timing Mark 860 ----- yes obs yes + 7 Remote Controlled Trans and Echo 726 39237 no yes no + 8 Output Line Width ... 20196 no yes no + 9 Output Page Size ... 20197 no yes no + 10 Output Carriage-Return Disposition 652 31155 no yes no + 11 Output Horizontal Tabstops 653 31156 no yes no + 12 Output Horizontal Tab Disposition 654 31157 no yes no + 13 Output Formfeed Disposition 655 31158 no yes no + 14 Output Vertical Tabstops 656 31159 no yes no + 15 Output Vertical Tab Disposition 657 31160 no yes no + 16 Output Linefeed Disposition 658 31161 no yes no + 17 Extended ASCII 698 32964 no yes no + 18 Logout 727 40025 no yes no + 19 Byte Macro 735 42083 no yes no + 20 Data Entry Terminal 732 41762 no yes no + 21 SUPDUP 734 736 42213 no yes no + 22 SUPDUP Output 749 45449 no no no + 23 Send Location 779 ----- no no no + 24 Terminal Type 884 ----- no no yes + 25 End of Record 885 ----- no no yes + 255 Extended-Options-List 861 ----- yes obs yes + + (obs = obsolete) + + The ITP column indicates if the specification is included in the + Internet Telnet Protocol and Options. The APH column indicates if + the specification is included in the ARPANET Protocol Handbook. + The USE column of the table above indicates which options are in + general use. + + COMMENTS: + + The Binary Transmission, Echo, Suppress Go Ahead, Status, + Timing Mark, and Extended Options List options have been + + +Reynolds & Postel [Page 11] + + + +Official ARPA-Internet Protocols RFC 901 + + + recently updated and reissued. These are the most frequently + implemented options. + + The remaining options should be reviewed and the useful ones + should be revised and reissued. The others should be + eliminated. + + The following are recommended: Binary Transmission, Echo, + Suppress Go Ahead, Status, Timing Mark, and Extended Options + List. + + OTHER REFERENCES: + + DEPENDENCIES: Telnet + + CONTACT: Postel@USC-ISIF.ARPA + + File Transfer Protocol (FTP) --------------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 765 (in IPTW) + + COMMENTS: + + The protocol for moving files between Internet hosts. Provides + for access control and negotiation of file parameters. + + There are a number of minor corrections to be made. A major + change is the deletion of the mail commands, and a major + clarification is needed in the discussion of the management of + the data connection. Also, a suggestion has been made to + include some directory manipulation commands (RFC 775). + + Even though the MAIL features are defined in this document, + they are not to be used. The SMTP protocol is to be used for + all mail service in the Internet. + + Data Connection Management: + + a. Default Data Connection Ports: All FTP implementations + must support use of the default data connection ports, and + only the User-PI may initiate the use of non-default ports. + + b. Negotiating Non-Default Data Ports: The User-PI may + specify a non-default user side data port with the PORT + command. The User-PI may request the server side to + identify a non-default server side data port with the PASV + command. Since a connection is defined by the pair of + + +Reynolds & Postel [Page 12] + + + +Official ARPA-Internet Protocols RFC 901 + + + addresses, either of these actions is enough to get a + different data connection, still it is permitted to do both + commands to use new ports on both ends of the data + connection. + + c. Reuse of the Data Connection: When using the stream + mode of data transfer the end of the file must be indicated + by closing the connection. This causes a problem if + multiple files are to be transfered in the session, due to + need for TCP to hold the connection record for a time out + period to guarantee the reliable communication. Thus the + connection can not be reopened at once. + + There are two solutions to this problem. The first is to + negotiate a non-default port (as in (b) above). The + second is to use another transfer mode. + + A comment on transfer modes. The stream transfer mode is + inherently unreliable, since one can not determine if the + connection closed prematurely or not. The other transfer + modes (Block, Compressed) do not close the connection to + indicate the end of file. They have enough FTP encoding + that the data connection can be parsed to determine the + end of the file. Thus using these modes one can leave + the data connection open for multiple file transfers. + + Why this was not a problem with the old NCP FTP: + + The NCP was designed with only the ARPANET in mind. + The ARPANET provides very reliable service, and the + NCP counted on it. If any packet of data from an NCP + connection were lost or damaged by the network the NCP + could not recover. It is a tribute to the ARPANET + designers that the NCP FTP worked so well. + + The TCP is designed to provide reliable connections + over many different types of networks and + interconnections of networks. TCP must cope with a + set of networks that can not promise to work as well + as the ARPANET. TCP must make its own provisions for + end-to-end recovery from lost or damaged packets. + This leads to the need for the connection phase-down + time-out. The NCP never had to deal with + acknowledgements or retransmissions or many other + things the TCP must do to make connection reliable in + a more complex world. + + LIST and NLST: + + + +Reynolds & Postel [Page 13] + + + +Official ARPA-Internet Protocols RFC 901 + + + There is some confusion about the LIST an NLST commands, and + what is appropriate to return. Some clarification and + motivation for these commands should be added to the + specification. + + OTHER REFERENCES: + + RFC 678 - Document File Format Standards + + MIL-STD-1780 - File Transfer Protocol (FTP) + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Trivial File Transfer Protocol (TFTP) ------------------------------ + + STATUS: Elective + + SPECIFICATION: RFC 783 (in IPTW) + + COMMENTS: + + A very simple file moving protocol, no access control is + provided. + + No known problems with this specification. This is in use in + several local networks. + + OTHER REFERENCES: + + DEPENDENCIES: User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Simple Mail Transfer Protocol (SMTP) ------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 821 (in "Internet Mail Protocols") + + COMMENTS: + + The procedure for transmitting computer mail between hosts. + + This has been revised since the IPTW, it is in the "Internet + Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is + obsolete. + + + +Reynolds & Postel [Page 14] + + + +Official ARPA-Internet Protocols RFC 901 + + + There have been many misunderstandings and errors in the early + implementations. Some documentation of these problems can be + found in the file [ISIF]MAIL.ERRORS. + + Some minor differences between RFC 821 and RFC 822 should be + resolved. + + OTHER REFERENCES: + + RFC 822 - Mail Header Format Standards + + This has been revised since the IPTW, it is in the "Internet + Mail Protocols" volume of November 1982. RFC 733 (in IPTW) + is obsolete. Further revision of RFC 822 is needed to + correct some minor errors in the details of the + specification. + + MIL-STD-1781 - Simple Mail Transfer Protocol (SMTP) + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Resource Location Protocol (RLP) ----------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 887 + + COMMENTS: + + A resource location protocol for use in the ARPA-Internet. + This protocol utilizes the User Datagram Protocol (UDP) which + in turn calls on the Internet Protocol to deliver its + datagrams. + + OTHER REFERENCES: + + DEPENDENCIES: User Datagram Protocol + + CONTACT: Accetta@CMU-CS-A.ARPA + + + + + + + + + + +Reynolds & Postel [Page 15] + + + +Official ARPA-Internet Protocols RFC 901 + + + Remote Job Entry (RJE) --------------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 407 (in APH) + + COMMENTS: + + The general protocol for submitting batch jobs and retrieving + the results. + + Some changes needed for use with TCP. + + No known active implementations. + + OTHER REFERENCES: + + DEPENDENCIES: File Transfer Protocol + Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Remote Job Service (NETRJS) ---------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 740 (in APH) + + COMMENTS: + + A special protocol for submitting batch jobs and retrieving the + results used with the UCLA IBM OS system. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + Revision in progress. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Braden@USC-ISIA.ARPA + + + + + + + + +Reynolds & Postel [Page 16] + + + +Official ARPA-Internet Protocols RFC 901 + + + Remote Telnet Service (RTELNET) ------------------------------------ + + STATUS: Elective + + SPECIFICATION: RFC 818 + + COMMENTS: + + Provides special access to user Telnet on a remote system. + + OTHER REFERENCES: + + DEPENDENCIES: Telnet, Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Graphics Protocol (GRAPHICS) --------------------------------------- + + STATUS: Elective + + SPECIFICATION: NIC 24308 (in APH) + + COMMENTS: + + The protocol for vector graphics. + + Very minor changes needed for use with TCP. + + No known active implementations. + + OTHER REFERENCES: + + DEPENDENCIES: Telnet, Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 17] + + + +Official ARPA-Internet Protocols RFC 901 + + + Echo Protocol (ECHO) ----------------------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 862 + + COMMENTS: + + Debugging protocol, sends back whatever you send it. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Discard Protocol (DISCARD) ----------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 863 + + COMMENTS: + + Debugging protocol, throws away whatever you send it. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Character Generator Protocol (CHARGEN) ----------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 864 + + COMMENTS: + + Debugging protocol, sends you ASCII data. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + + +Reynolds & Postel [Page 18] + + + +Official ARPA-Internet Protocols RFC 901 + + + CONTACT: Postel@USC-ISIF.ARPA + + Quote of the Day Protocol (QUOTE) ---------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 865 + + COMMENTS: + + Debugging protocol, sends you a short ASCII message. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Active Users Protocol (USERS) -------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 866 + + COMMENTS: + + Lists the currently active users. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Finger Protocol (FINGER) ------------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 742 (in APH) + + COMMENTS: + + Provides information on the current or most recent activity of + a user. + + Some extensions have been suggested. + + + +Reynolds & Postel [Page 19] + + + +Official ARPA-Internet Protocols RFC 901 + + + Some changes are are needed for TCP. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + WhoIs Protocol (NICNAME) ------------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 812 (in IPTW) + + COMMENTS: + + Accesses the ARPANET Directory database. Provides a way to + find out about people, their addresses, phone numbers, + organizations, and mailboxes. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Feinler@SRI-NIC.ARPA + + Domain Name Protocol (DOMAIN) + + STATUS: Experimental + + SPECIFICATION: RFC 881, 882, 883 + + COMMENTS: + + OTHER REFERENCES: + + RFC 897 - Domain Name Implementation Schedule + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Mockapetris@USC-ISIF.ARPA + + + + + + + + + + +Reynolds & Postel [Page 20] + + + +Official ARPA-Internet Protocols RFC 901 + + + HOSTNAME Protocol (HOSTNAME) --------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 811 (in IPTW) + + COMMENTS: + + Accesses the Registered Internet Hosts database (HOSTS.TXT). + Provides a way to find out about a host in the Internet, its + Internet Address, and the protocols it implements. + + OTHER REFERENCES: + + RFC 810 - Host Table Specification + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Feinler@SRI-NIC.ARPA + + Host Name Server Protocol (NAMESERVER) ----------------------------- + + STATUS: Experimental + + SPECIFICATION: IEN 116 (in IPTW) + + COMMENTS: + + Provides machine oriented procedure for translating a host name + to an Internet Address. + + This specification has significant problems: 1) The name + syntax is out of date. 2) The protocol details are ambiguous, + in particular, the length octet either does or doesn't include + itself and the op code. 3) The extensions are not supported by + any known implementation. + + Work is in progress on a significant revision. Further + implementations of this protocol are not advised. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + +Reynolds & Postel [Page 21] + + + +Official ARPA-Internet Protocols RFC 901 + + + CSNET Mailbox Name Server Protocol (CSNET-NS) ---------------------- + + STATUS: Experimental + + SPECIFICATION: CS-DN-2 + + COMMENTS: + + Provides access to the CSNET data base of users to give + information about users names, affiliations, and mailboxes. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Solomon@UWISC.ARPA + + Daytime Protocol (DAYTIME) ----------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 867 + + COMMENTS: + + Provides the day and time in ASCII character string. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Time Server Protocol (TIME) ---------------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 868 + + COMMENTS: + + Provides the time as the number of seconds from a specified + reference time. + + OTHER REFERENCES: + + +Reynolds & Postel [Page 22] + + + +Official ARPA-Internet Protocols RFC 901 + + + DEPENDENCIES: Transmission Control Protocol + or User Datagram Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + DCNET Time Server Protocol (CLOCK) --------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 778 + + COMMENTS: + + Provides a mechanism for keeping synchronized clocks. + + OTHER REFERENCES: + + DEPENDENCIES: Internet Control Message Protocol + + CONTACT: Mills@USC-ISID.ARPA + + SUPDUP Protocol (SUPDUP) ------------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 734 (in APH) + + COMMENTS: + + A special Telnet like protocol for display terminals. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Admin.MRC@SU-SCORE.ARPA + + + + + + + + + + + + + + + +Reynolds & Postel [Page 23] + + + +Official ARPA-Internet Protocols RFC 901 + + + Internet Message Protocol (MPM) ------------------------------------ + + STATUS: Experimental + + SPECIFICATION: RFC 759 + + COMMENTS: + + This is an experimental multimedia mail transfer protocol. The + implementation is called a Message Processing Module or MPM. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + RFC 767 - Structured Document Formats + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + Post Office Protocol (POP) ----------------------------------------- + + STATUS: Experimental + + SPECIFICATION: RFC xxx + + COMMENTS: + + This is an experimental procedure for accessing mailbox + services from personal workstations. + + Please discuss any plans for implementation or use of this + protocol with the contact. + + OTHER REFERENCES: + + DEPENDENCIES: Transmission Control Protocol + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + +Reynolds & Postel [Page 24] + + + +Official ARPA-Internet Protocols RFC 901 + + + Network Standard Text Editor (NETED) ------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 569 + + COMMENTS: + + Describes a simple line editor which could be provided by every + Internet host. + + OTHER REFERENCES: + + DEPENDENCIES: + + CONTACT: Postel@USC-ISIF.ARPA + +Appendices + + Assigned Numbers --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 900 + + COMMENTS: + + Describes the fields of various protocols that are assigned + specific values for actual use, and lists the currently + assigned values. + + Issued June 1984, replaces RFC 870, RFC 790 in IPTW, and + RFC 820 of January 1983. + + OTHER REFERENCES: + + CONTACT: JKReynolds@USC-ISIF.ARPA + + + + + + + + + + + + + + +Reynolds & Postel [Page 25] + + + +Official ARPA-Internet Protocols RFC 901 + + + Pre-emption -------------------------------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 794 (in IPTW) + + COMMENTS: + + Describes how to do pre-emption of TCP connections. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Service Mappings --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 795 (in IPTW) + + COMMENTS: + + Describes the mapping of the IP type of service field onto the + parameters of some specific networks. + + Out of date, needs revision. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Address Mappings --------------------------------------------------- + + STATUS: None + + SPECIFICATION: RFC 796 (in IPTW) + + COMMENTS: + + Describes the mapping between Internet Addresses and the + addresses of some specific networks. + + Out of date, needs revision. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + +Reynolds & Postel [Page 26] + + + +Official ARPA-Internet Protocols RFC 901 + + + Internet Protocol on X.25 Networks --------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 877 + + COMMENTS: + + Describes a standard for the transmission of IP Datagrams over + Public Data Networks. + + OTHER REFERENCES: + + CONTACT: jtk@PURDUE.ARPA + + Internet Protocol on DC Networks ----------------------------------- + + STATUS: Elective + + SPECIFICATION: RFC 891 + + COMMENTS: + + OTHER REFERENCES: + + RFC 778 - DCNET Internet Clock Service + + CONTACT: Mills@USC-ISID.ARPA + + Internet Protocol on Ethernet Networks ----------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 894 + + COMMENTS: + + OTHER REFERENCES: + + RFC 893 + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + +Reynolds & Postel [Page 27] + + + +Official ARPA-Internet Protocols RFC 901 + + + Internet Protocol on Experimental Ethernet Networks ---------------- + + STATUS: Recommended + + SPECIFICATION: RFC 895 + + COMMENTS: + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + Address Resolution Protocol (ARP) ---------------------------------- + + STATUS: Recommended + + SPECIFICATION: RFC 826 + + COMMENTS: + + This is a procedure for finding the network hardware address + corresponding to an Internet Address. + + OTHER REFERENCES: + + CONTACT: Postel@USC-ISIF.ARPA + + + + + + + + + + + + + + + + + + + + + + + + + +Reynolds & Postel [Page 28] + -- cgit v1.2.3