summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc840.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc840.txt')
-rw-r--r--doc/rfc/rfc840.txt1334
1 files changed, 1334 insertions, 0 deletions
diff --git a/doc/rfc/rfc840.txt b/doc/rfc/rfc840.txt
new file mode 100644
index 0000000..69c89ff
--- /dev/null
+++ b/doc/rfc/rfc840.txt
@@ -0,0 +1,1334 @@
+
+
+Network Working Group J. Postel
+Request for Comments: 840 ISI
+ April 1983
+
+ Official Protocols
+
+
+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 these are noted here. In particular, the
+mail protocols have been revised and issued as a volume titled "Internet
+Mail Protocols" dated November 1982. There is a volume of protocol
+related information called the Internet Protocol Implementers Guide
+(IPIG) dated August 1982. A few of the protocols (in particular the
+Telnet Options) have not been revised for many years, these are found in
+the old ARPANET Protocol Handbook (APH) dated January 1978.
+
+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.
+
+ The contact indicates a person who can answer questions about the
+ protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 1]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ In particular, the status may need some further clarification:
+
+ 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.
+
+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:
+
+ DEPENDENCIES:
+
+ CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+Postel [Page 2]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+Network Level
+
+ Internet Protocol (IP)
+
+ STATUS: Required
+
+ SPECIFICATION: RFC 791 (in IPTW)
+
+ COMMENTS:
+
+ 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.
+
+ 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
+
+ DEPENDENCIES:
+
+ CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+Postel [Page 3]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Internet Control Message Protocol (ICMP)
+
+ STATUS: Required
+
+ SPECIFICATION: RFC 792 (in IPTW)
+
+ COMMENTS:
+
+ 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.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Internet Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+Host Level
+
+ User Datagram Protocol (UDP)
+
+ STATUS: Recommended
+
+ SPECIFICATION: RFC 768 (in IPTW)
+
+ COMMENTS:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 4]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Transmission Control Protocol (TCP)
+
+ STATUS: Recommended
+
+ SPECIFICATION: RFC 793 (in IPTW)
+
+ COMMENTS:
+
+ 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
+ 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 default should be established more clearly. The default is
+ based on the default maximum Internet Datagram size which is
+ 576 octets counting the IP and TCP headers. The option counts
+ only the segment data. For each of IP and TCP the minimum
+ header is 20 octets and the maximum header is 60 octets. So the
+ default maximum data segment is could be anywhere from 456 to
+ 536 octets. The current proposal is to set it at 536 data
+ octets.
+
+ 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,
+
+
+Postel [Page 5]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ 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
+
+ DEPENDENCIES: Internet Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Host Monitoring Protocol (HMP)
+
+ STATUS: Elective
+
+ SPECIFICATION: IEN 197
+
+ COMMENTS:
+
+ This is a good tool for debuging protocol implementations in
+ small remotely located computers.
+
+ This protocol is used to monitor Internet gateways and the
+ TACs.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Internet Protocol
+
+ CONTACT: Hinden@BBN-UNIX
+
+
+Postel [Page 6]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Cross Net Debugger (XNET)
+
+ STATUS: Elective
+
+ SPECIFICATION: IEN 158
+
+ COMMENTS:
+
+ This specification should be updated and reissued as an RFC.
+
+ OTHER REFERENCES:
+
+ RFC 643
+
+ DEPENDENCIES: Internet Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Exterior Gateway Protocol (EGP)
+
+ STATUS: Experimental
+
+ SPECIFICATION: RFC 827
+
+ COMMENTS:
+
+ Please discuss any plans for implementation or use of this
+ protocol with the contact.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Internet Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 7]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Gateway Gateway Protocol (GGP)
+
+ STATUS: Experimental
+
+ SPECIFICATION: RFC 823
+
+ COMMENTS:
+
+ Please discuss any plans for implementation or use of this
+ protocol with the contact.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Internet Protocol
+
+ CONTACT: Brescia@BBN-UNIX
+
+ Multiplexing Protocol
+
+ STATUS: Experimental
+
+ SPECIFICATION: IEN 90
+
+ COMMENTS:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 8]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Stream Protocol (ST)
+
+ STATUS: Experimental
+
+ SPECIFICATION: IEN 119
+
+ COMMENTS:
+
+ 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: Forgie@BBN
+
+ Network Voice Protocol (NVP-II)
+
+ STATUS: Experimental
+
+ SPECIFICATION: RFC xxx
+
+ COMMENTS:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 9]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+Application Level
+
+ Telnet Protocol (TELNET)
+
+ STATUS: Recommended
+
+ SPECIFICATION: RFC 764 (in IPTW)
+
+ COMMENTS:
+
+ A few minor typographical errors should be corrected and some
+ clarification of the SYNCH mechanism should be made.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Telnet Options (TELNET)
+
+ Number Name RFC NIC APH USE
+ ------ ------------------------------------ --- ----- --- ---
+ 0 Binary Transmission ... 15389 yes yes
+ 1 Echo ... 15390 yes yes
+ 2 Reconnection ... 15391 yes no
+ 3 Suppress Go Ahead ... 15392 yes yes
+ 4 Approximate Message Size Negotiation ... 15393 yes no
+ 5 Status 651 31154 yes yes
+ 6 Timing Mark ... 16238 yes yes
+ 7 Remote Controlled Trans and Echo 726 39237 yes no
+ 8 Output Line Width ... 20196 yes no
+ 9 Output Page Size ... 20197 yes no
+ 10 Output Carriage-Return Disposition 652 31155 yes no
+ 11 Output Horizontal Tabstops 653 31156 yes no
+ 12 Output Horizontal Tab Disposition 654 31157 yes no
+ 13 Output Formfeed Disposition 655 31158 yes no
+ 14 Output Vertical Tabstops 656 31159 yes no
+ 15 Output Vertical Tab Disposition 657 31160 yes no
+ 16 Output Linefeed Disposition 658 31161 yes no
+ 17 Extended ASCII 698 32964 yes no
+ 18 Logout 727 40025 yes no
+ 19 Byte Macro 735 42083 yes no
+ 20 Data Entry Terminal 732 41762 yes no
+ 21 SUPDUP 734 736 42213 yes no
+ 22 SUPDUP Output 749 45449 no no
+ 23 Send Location 779 ----- no no
+ 255 Extended-Options-List ... 16239 yes yes
+
+
+
+Postel [Page 10]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ STATUS: Elective
+
+ SPECIFICATION: (in APH)
+
+ COMMENTS:
+
+ There is an open question about some of these. Most of the
+ options are implemented by so few hosts that perhaps they
+ should be eliminated. These should all be studied and the
+ useful ones reissued as RFCs.
+
+ The last column (USE) of the table above indicates which
+ options are in general use.
+
+ The following are recommended: Binary Transmission, Echo,
+ Suppress Go Ahead, Status, Timing Mark, and Extended Options
+ List.
+
+ Many of these must be revised for use with TCP.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Telnet
+
+ CONTACT: Postel@USC-ISIF
+
+ File Transfer Protocol (FTP)
+
+ STATUS: Recommended
+
+ SPECIFICATION: RFC 765 (in IPTW)
+
+ COMMENTS:
+
+ 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).
+
+ Eventhough 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.
+
+
+Postel [Page 11]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ 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
+ 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
+
+
+Postel [Page 12]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ things the TCP must do to make connection reliable in
+ a more complex world.
+
+ LIST and NLST:
+
+ 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
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Trivial File Transfer Protocol (TFTP)
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 783 (in IPTW)
+
+ COMMENTS:
+
+ No known problems with this specification. This is in use in
+ several local networks.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Simple Mail Transfer Protocol (SMTP)
+
+ STATUS: Recommended
+
+ SPECIFICATION: RFC 821
+
+ COMMENTS:
+
+ This has been revised since the IPTW, it is in the "Internet
+ Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is
+ obsolete.
+
+ There have been many misunderstandings and errors in the early
+
+
+
+Postel [Page 13]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ implementations. Some documentation of these problems can be
+ found in the file [ISIF]<SMTP>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.
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Remote Job Entry (RJE)
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 407 (in APH)
+
+ COMMENTS:
+
+ Some changes needed for use with TCP.
+
+ No known active implementations.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: File Transfer Protocol
+ Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 14]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Remote Job Service (NETRJS)
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 740 (in APH)
+
+ COMMENTS:
+
+ 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
+
+ Remote Telnet Service
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 818
+
+ COMMENTS:
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Telnet, Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Graphics Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: NIC 24308 (in APH)
+
+ COMMENTS:
+
+ Very minor changes needed for use with TCP.
+
+ No known active implementations.
+
+ OTHER REFERENCES:
+
+
+
+Postel [Page 15]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ DEPENDENCIES: Telnet, Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Echo Protocol
+
+ STATUS: Recommended
+
+ SPECIFICATION: RFC 347
+
+ COMMENTS:
+
+ This specification should be revised for use with TCP and
+ reissued.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Discard Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 348
+
+ COMMENTS:
+
+ This specification should be revised for use with TCP and
+ reissued.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 16]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ Character Generator Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 429
+
+ COMMENTS:
+
+ This specification should be revised for use with TCP and
+ reissued.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Quote of the Day Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC xxx
+
+ COMMENTS:
+
+ Open a connection to this server, it sends you a quote (as a
+ character string), and closes the connection. This should be
+ described in an RFC.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Active Users Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC xxx
+
+ COMMENTS:
+
+ Open a connection to this server, it sends you a list of the
+ currently logged in users (as a character string), and closes
+ the connection. This should be described in an RFC.
+
+
+
+Postel [Page 17]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Finger Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 742 (in APH)
+
+ COMMENTS:
+
+ Some extensions have been suggested.
+
+ Some changes are are needed for TCP.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ NICNAME Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 812 (in IPTW)
+
+ COMMENTS:
+
+ Accesses the ARPANET Directory database.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Feinler@SRI-NIC
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 18]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ HOSTNAME Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 811 (in IPTW)
+
+ COMMENTS:
+
+ Accesses the Registered Internet Hosts database (HOSTS.TXT).
+
+ OTHER REFERENCES:
+
+ RFC 810 - Host Table Specification
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Feinler@SRI-NIC
+
+ Host Name Server Protocol
+
+ STATUS: Experimental
+
+ SPECIFICATION: IEN 116 (in IPTW)
+
+ COMMENTS:
+
+ 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
+
+
+
+
+
+
+
+
+Postel [Page 19]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ CSNET Mailbox Name Server Protocol
+
+ STATUS: Experimental
+
+ SPECIFICATION: CS-DN-2
+
+ COMMENTS:
+
+ Please discuss any plans for implementation or use of this
+ protocol with the contact.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Solomon@UWISC
+
+ Daytime Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC xxx
+
+ COMMENTS:
+
+ Open a connection to this server, it sends you the date and
+ time (as a character string), and closes the connection. This
+ should be described in an RFC.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ Time Server Protocol
+
+ STATUS: Recommended
+
+ SPECIFICATION: IEN 142
+
+ COMMENTS:
+
+ Open a connection to this server, it sends you the date and
+ time (as a 32-bit number), and closes the connection. Or send
+ a user datagram and it send back a datagram containing the date
+ and time (as a 32-bit number).
+
+
+
+Postel [Page 20]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ No known problems. Specification should be reissued as an RFC.
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+ or User Datagram Protocol
+
+ CONTACT: Postel@USC-ISIF
+
+ DCNET Time Server Protocol (Internet Clock Service)
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 778
+
+ COMMENTS:
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Internet Control Message Protocol
+
+ CONTACT: Mills@LINKABIT-DCN6
+
+ SUPDUP Protocol
+
+ STATUS: Elective
+
+ SPECIFICATION: RFC 734 (in APH)
+
+ COMMENTS:
+
+ OTHER REFERENCES:
+
+ DEPENDENCIES: Transmission Control Protocol
+
+ CONTACT: Admin.MRC@SU-SCORE
+
+ Internet Message Protocol (MPM)
+
+ STATUS: Experimental
+
+ SPECIFICATION: RFC 753
+
+ COMMENTS:
+
+ This is an experimental multimedia mail transfer protocol. The
+ implementation is called a Message Processing Module or MPM.
+
+
+
+
+Postel [Page 21]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ 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
+
+Appendices
+
+ Assigned Numbers
+
+ STATUS: None
+
+ SPECIFICATION: RFC 820
+
+ COMMENTS:
+
+ Describes the fields of various protocols that are assigned
+ specific values for actual use, and lists the currently
+ assigned values.
+
+ Issued January 1983, replaces RFC 790 in IPTW.
+
+ OTHER REFERENCES:
+
+ CONTACT: Postel@USC-ISIF
+
+ 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
+
+
+
+
+
+
+
+Postel [Page 22]
+
+
+RFC 840 April 1983
+ Official Protocols
+
+
+ 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
+
+ Address Mappings
+
+ STATUS: None
+
+ SPECIFICATION: RFC 796 (in IPTW)
+
+ COMMENTS:
+
+ Describes the mapping of the IP address field onto the address
+ field of some specific networks.
+
+ Out of date, needs revision.
+
+ OTHER REFERENCES:
+
+ CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel [Page 23]
+