doc: Add RFC documents

1 files changed, 1508 insertions, 0 deletions

diff --git a/doc/rfc/rfc880.txt b/doc/rfc/rfc880.txt
new file mode 100644
index 0000000..fe54bc0
--- /dev/null
+++ b/doc/rfc/rfc880.txt
@@ -0,0 +1,1508 @@
+
+
+Network Working Group                                        J. Reynolds
+Request for Comments: 880                                      J. Postel
+                                                                     ISI
+Obsoletes: RFC 840                                          October 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.  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.
+
+   The contact indicates a person who can answer questions about the
+   protocol.
+
+
+
+
+
+
+
+
+Reynolds & Postel                                               [Page 1]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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.
+
+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
+
+
+
+
+Reynolds & Postel                                               [Page 2]
+
+
+
+Official Protocols                                               RFC 880
+
+
+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.
+
+         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
+
+
+
+
+
+
+Reynolds & Postel                                               [Page 3]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+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
+
+
+
+Reynolds & Postel                                               [Page 4]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+         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
+
+
+Reynolds & Postel                                               [Page 5]
+
+
+
+Official Protocols                                               RFC 880
+
+
+         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
+
+      DEPENDENCIES: Internet Protocol
+
+      CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                               [Page 6]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   Host Monitoring Protocol (HMP)  -------------------------------------
+
+      STATUS:  Elective
+
+      SPECIFICATION:  IEN 197
+
+      COMMENTS:
+
+         This is a good tool for debugging 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
+
+   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
+
+      DEPENDENCIES: Internet Protocol
+
+      CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                               [Page 7]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   Exterior Gateway Protocol (EGP)  ------------------------------------
+
+      STATUS:  Experimental
+
+      SPECIFICATION:  RFC 827
+
+      COMMENTS:
+
+         The gateway protocol now under development.
+
+         Please discuss any plans for implementation or use of this
+         protocol with the contact.
+
+      OTHER REFERENCES:
+
+      DEPENDENCIES: Internet Protocol
+
+      CONTACT: Mills@USC-ISID
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                               [Page 8]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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: Forgie@BBN
+
+
+Reynolds & Postel                                               [Page 9]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+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:
+
+      DEPENDENCIES: Transmission Control Protocol
+
+      CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 10]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+       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
+         recently updated and reissued.  These are the most frequently
+         implemented options.
+
+
+Reynolds & Postel                                              [Page 11]
+
+
+
+Official Protocols                                               RFC 880
+
+
+         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
+
+   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
+            addresses, either of these actions is enough to get a
+            different data connection, still it is permitted to do both
+
+
+
+Reynolds & Postel                                              [Page 12]
+
+
+
+Official Protocols                                               RFC 880
+
+
+            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:
+
+            There is some confusion about the LIST an NLST commands, and
+            what is appropriate to return.  Some clarification and
+
+
+Reynolds & Postel                                              [Page 13]
+
+
+
+Official Protocols                                               RFC 880
+
+
+            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:
+
+         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
+
+   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.
+
+         There have been many misunderstandings and errors in the early
+         implementations.  Some documentation of these problems can be
+         found in the file [ISIF]<SMTP>MAIL.ERRORS.
+
+
+
+Reynolds & Postel                                              [Page 14]
+
+
+
+Official Protocols                                               RFC 880
+
+
+         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:
+
+         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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 15]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 16]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   Graphics Protocol (GRAPHICS)  ---------------------------------------
+
+      STATUS:  Elective
+
+      SPECIFICATION:  NIC 24308 (in APH)
+
+      COMMENTS:
+
+         The protocols 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
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 17]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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
+
+      CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 18]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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
+
+   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.
+
+         Some changes are are needed for TCP.
+
+
+
+Reynolds & Postel                                              [Page 19]
+
+
+
+Official Protocols                                               RFC 880
+
+
+      OTHER REFERENCES:
+
+      DEPENDENCIES: Transmission Control Protocol
+
+      CONTACT: Postel@USC-ISIF
+
+   NICNAME 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
+
+   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
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 20]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   CSNET Mailbox Name Server Protocol (CSNET-NAMESERVER)  --------------
+
+      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
+
+
+
+Reynolds & Postel                                              [Page 21]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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:
+
+      DEPENDENCIES: Transmission Control Protocol
+                    or User Datagram Protocol
+
+      CONTACT: Postel@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 22]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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
+
+   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
+
+
+Reynolds & Postel                                              [Page 23]
+
+
+
+Official Protocols                                               RFC 880
+
+
+      DEPENDENCIES: Transmission Control Protocol
+
+      CONTACT: Postel@USC-ISIF
+
+   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
+
+Appendices
+
+   Assigned Numbers  ---------------------------------------------------
+
+      STATUS:  None
+
+      SPECIFICATION:  RFC 870
+
+      COMMENTS:
+
+         Describes the fields of various protocols that are assigned
+         specific values for actual use, and lists the currently
+         assigned values.
+
+         Issued October 1983, replaces RFC 790 in IPTW, and RFC 820 of
+         January 1983.
+
+      OTHER REFERENCES:
+
+      CONTACT: JKReynolds@USC-ISIF
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 24]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+   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 between Internet Addresses and the
+         addresses of some specific networks.
+
+         Out of date, needs revision.
+
+      OTHER REFERENCES:
+
+      CONTACT:  Postel@USC-ISIF
+
+
+
+
+Reynolds & Postel                                              [Page 25]
+
+
+
+Official Protocols                                               RFC 880
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds & Postel                                              [Page 26]
+