Network Working Group
`Request for Comments: 1011
`
`Obsoletes: RFCs 991, 961, 943, 924, 901, 880, 840
`
`J. Reynolds
`J. Postel
`ISI
`May 1987
`
`OFFICIAL INTERNET PROTOCOLS
`
`STATUS OF THIS MEMO
`
` This memo is an official status report on the protocols used in the
` Internet community. Distribution of this memo is unlimited.
`
`INTRODUCTION
`
` This RFC identifies the documents specifying the official protocols
` used in the Internet. Comments indicate any revisions or changes
` planned.
`
` To first order, the official protocols are those specified in the
` "DDN Protocol Handbook" (DPH), dated December 1985 (this is a three
` volume set with a total thickness of about 5 inches).
`
` Older collections that include many of these specifications are the
` "Internet Protocol Transition Workbook" (IPTW), dated March 1982; the
` "Internet Mail Protocols", dated November 1982; and the "Internet
` Telnet Protocols and Options", dated June 1983. There is also a
` volume of protocol related information called the "Internet Protocol
` Implementers Guide" (IPIG) dated August 1982. An even older
` collection is the "ARPANET Protocol Handbook" (APH) dated
` January 1978. Nearly all the relevant material from these
` collections has been reproduced in the current DPH.
`
` The following material 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,
`experimental, or none.
`
`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.
`
`Reynolds & Postel
`
`[Page 1]
`
`EX 1012 Page 1
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` The DEPENDENCIES indicate what other protocols are called upon by
` this protocol.
`
` 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 K. Reynolds
` USC - Information Sciences Institute
` 4676 Admiralty Way
` Marina del Rey, California 90292-6695
`
` Phone: (213) 822-1511
`
` Electronic mail: JKREYNOLDS@ISI.EDU
`
`Reynolds & Postel [Page 2]
`
`EX 1012 Page 2
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
`OVERVIEW
`
` Catenet Model ------------------------------------------------------
`
` STATUS: None
`
` SPECIFICATION: IEN 48 (in DPH)
`
` COMMENTS:
`
` Gives an overview of the organization and principles of the
` Internet.
`
` Could be revised and expanded.
`
` OTHER REFERENCES:
`
` Leiner, B., Cole R., Postel, J., and D. Mills, "The DARPA
` Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985.
` Also in IEEE Communications Magazine, and as ISI/RS-85-153,
` March 1985.
`
` Postel, J., "Internetwork Applications Using the DARPA Protocol
` Suite", IEEE INFOCOM 85, Washington, D.C., March 1985. Also in
` IEEE Communications Magazine, and as ISI/RS-85-151, April 1985.
`
` Padlipsky, M.A., "The Elements of Networking Style and other
` Essays and Animadversions on the Art of Intercomputer
` Networking", Prentice-Hall, New Jersey, 1985.
`
` RFC 871 - A Perspective on the ARPANET Reference Model
`
` DEPENDENCIES:
`
` CONTACT: Postel@ISI.EDU
`
`Reynolds & Postel [Page 3]
`
`EX 1012 Page 3
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
`NETWORK LEVEL
`
` Internet Protocol --------------------------------------------- (IP)
`
` STATUS: Required
`
` SPECIFICATION: RFC 791 (in DPH)
`
` 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. The MIL-STD description of source routing is wrong in
` some of the details.
`
` Another important point is the alternate reassembly procedure
` suggested in RFC 815.
`
` Some changes are in the works for the security option.
`
` 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.
`
` The subnet procedures defined in RFC 950 are now considered an
` essential part of the IP architecture and must be implemented
` by all hosts and gateways.
`
` OTHER REFERENCES:
`
` RFC 815 (in DPH) - IP Datagram Reassembly Algorithms
`
` RFC 814 (in DPH) - Names, Addresses, Ports, and Routes
`
` RFC 816 (in DPH) - Fault Isolation and Recovery
`
`Reynolds & Postel [Page 4]
`
`EX 1012 Page 4
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` RFC 817 (in DPH) - Modularity and Efficiency in Protocol
` Implementation
`
` MIL-STD-1777 (in DPH) - Military Standard Internet Protocol
`
` RFC 963 - Some Problems with the Specification of the Military
` Standard Internet Protocol
`
` DEPENDENCIES:
`
` CONTACT: Postel@ISI.EDU
`
` Internet Control Message Protocol --------------------------- (ICMP)
`
` STATUS: Required
`
` SPECIFICATION: RFC 792 (in DPH)
`
` 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.
`
` Two additional ICMP message types are defined in RFC 950
` "Internet Subnets", Address Mask Request (A1=17), and Address
` Mask Reply (A2=18).
`
` 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 950
`
` DEPENDENCIES: Internet Protocol
`
` CONTACT: Postel@ISI.EDU
`
`Reynolds & Postel [Page 5]
`
`EX 1012 Page 5
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Internet Group Multicast Protocol --------------------------- (IGMP)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 988
`
` COMMENTS:
`
` This protocol specifies the extensions required of a host
` implementation of the Internet Protocol (IP) to support
` internetwork multicasting. This specification supersedes that
` given in RFC 966, and constitutes a proposed protocol standard
` for IP multicasting in the Internet. Reference RFC 966 for a
` discussion of the motivation and rationale behind the
` multicasting extension specified here.
`
` OTHER REFERENCES: RFC 966
`
` DEPENDENCIES: Internet Protocol
`
` CONTACT: Deering@PESCADERO.STANFORD.EDU
`
`Reynolds & Postel [Page 6]
`
`EX 1012 Page 6
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
`HOST LEVEL
`
` User Datagram Protocol --------------------------------------- (UDP)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 768 (in DPH)
`
` 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@ISI.EDU
`
` Transmission Control Protocol -------------------------------- (TCP)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 793 (in DPH)
`
` 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.
`
`Reynolds & Postel [Page 7]
`
`EX 1012 Page 7
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Urgent: Page 17 is wrong. The urgent pointer points to the
` last octet of urgent data (not to the first octet of non-urgent
` data).
`
` 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 TCP Maximum Segment Size is the IP Maximum Datagram Size
` minus forty. The default IP Maximum Datagram Size is 576. The
` default TCP Maximum Segment 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.
`
`Reynolds & Postel [Page 8]
`
`EX 1012 Page 8
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` OTHER REFERENCES:
`
` RFC 813 (in DPH) - Window and Acknowledgement Strategy in TCP
`
` RFC 814 (in DPH) - Names, Addresses, Ports, and Routes
`
` RFC 816 (in DPH) - Fault Isolation and Recovery
`
` RFC 817 (in DPH) - Modularity and Efficiency in Protocol
` Implementation
`
` RFC 879 - TCP Maximum Segment Size
`
` RFC 889 - Internet Delay Experiments
`
` RFC 896 - TCP/IP Congestion Control
`
` MIL-STD-1778 (in DPH) - Military Standard Transmission Control
` Protocol
`
` RFC 964 - Some Problems with the Specification of the Military
` Standard Transmission Control Protocol
`
` Zhang, Lixia, "Why TCP Timers Don’t Work Well", Communications
` Architectures and Protocols, ACM SIGCOMM Proceedings, Computer
` Communications Review, V.16, N.3, August 1986.
`
` DEPENDENCIES: Internet Protocol
`
` CONTACT: Postel@ISI.EDU
`
` Bulk Data Transfer Protocol ------------------------------- (NETBLT)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 998
`
` COMMENTS:
`
` This is a revised RFC on the discussion of the Network Block
` Transfer (NETBLT) protocol.
`
` NETBLT (NETwork BLock Transfer) is a transport level protocol
` intended for the rapid transfer of a large quantity of data
` between computers. It provides a transfer that is reliable and
` flow controlled, and is designed to provide maximum throughput
` over a wide variety of networks. Although NETBLT currently
`
`Reynolds & Postel [Page 9]
`
`EX 1012 Page 9
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` runs on top of the Internet Protocol (IP), it should be able to
` operate on top of any datagram protocol similar in function to
` IP.
`
` This document is published for discussion and comment, and does
` not constitute a standard. The proposal may change and certain
` parts of the protocol have not yet been specified;
` implementation of this document is therefore not advised.
`
` OTHER REFERENCES: RFC 969
`
` DEPENDENCIES: Transmission Control Protocol, User Datagram
` Protocol
`
` CONTACT: markl@PTT.LCS.MIT.EDU
`
` Exterior Gateway Protocol ------------------------------------ (EGP)
`
` STATUS: Recommended for Gateways
`
` SPECIFICATION: RFC 888, RFC 904 (in DPH), RFC 975, RFC 985
`
` COMMENTS:
`
` The protocol used between gateways of different administrations
` to exchange routing information.
`
` 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@UDEL.EDU
`
`Reynolds & Postel [Page 10]
`
`EX 1012 Page 10
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Gateway Gateway Protocol ------------------------------------- (GGP)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 823 (in DPH)
`
` 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.COM
`
` Host Monitoring Protocol ------------------------------------- (HMP)
`
` STATUS: Elective
`
` SPECIFICATION: RFC 869 (in DPH)
`
` 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.COM
`
`Reynolds & Postel [Page 11]
`
`EX 1012 Page 11
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Reliable Data Protocol --------------------------------------- (RDP)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 908 (in DPH)
`
` COMMENTS:
`
` This protocol is designed to efficiently support the bulk
` transfer of data for such host monitoring and control
` applications as loading/dumping and remote debugging. The
` protocol is intended to be simple to implement but still be
` efficient in environments where there may be long transmission
` delays and loss or non-sequential delivery of message segments.
`
` Please discuss any plans for implementation or use of this
` protocol with the contact.
`
` OTHER REFERENCES:
`
` DEPENDENCIES: Internet Protocol
`
` CONTACT: CWelles@BBN.COM
`
` Internet Reliable Transaction Protocol ---------------------- (IRTP)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 938
`
` COMMENTS:
`
` This protocol is a transport level host to host protocol
` designed for an internet environment. While the issues
` discussed may not be directly relevant to the research problems
` of the Internet community, they may be interesting to a number
` of researchers and implementors.
`
` OTHER REFERENCES:
`
` DEPENDENCIES: Internet Protocol
`
` CONTACT: Trudy@ACC.ARPA
`
`Reynolds & Postel [Page 12]
`
`EX 1012 Page 12
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Cross Net Debugger ------------------------------------------ (XNET)
`
` STATUS: Elective
`
` SPECIFICATION: IEN 158 (in DPH)
`
` 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@ISI.EDU
`
` Multiplexing Protocol ---------------------------------------- (MUX)
`
` STATUS: Experimental
`
` SPECIFICATION: IEN 90 (in DPH)
`
` 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@ISI.EDU
`
`Reynolds & Postel [Page 13]
`
`EX 1012 Page 13
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Stream Protocol ----------------------------------------------- (ST)
`
` STATUS: Experimental
`
` SPECIFICATION: IEN 119 (in DPH)
`
` 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
`
` Network Voice Protocol ------------------------------------ (NVP-II)
`
` STATUS: Experimental
`
` SPECIFICATION: ISI Internal Memo
`
` 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: RFC 741 (in DPH)
`
` DEPENDENCIES: Internet Protocol, Stream Protocol
`
` CONTACT: Casner@ISI.EDU
`
`Reynolds & Postel [Page 14]
`
`EX 1012 Page 14
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
`APPLICATION LEVEL
`
` Telnet Protocol ------------------------------------------- (TELNET)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 854 (in DPH)
`
` 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 (in DPH) - Telnet Protocol
`
` DEPENDENCIES: Transmission Control Protocol
`
` CONTACT: Postel@ISI.EDU
`
`Reynolds & Postel [Page 15]
`
`EX 1012 Page 15
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Telnet Options ------------------------------------ (TELNET-OPTIONS)
`
` STATUS: Elective
`
` SPECIFICATION: General description of options: RFC 855 (in DPH)
`
` Number Name RFC NIC DPH USE
` ------ --------------------------------- --- ----- --- ---
` 0 Binary Transmission 856 ----- yes yes
` 1 Echo 857 ----- yes yes
` 2 Reconnection ... 15391 yes no
` 3 Suppress Go Ahead 858 ----- yes yes
` 4 Approx Message Size Negotiation ... 15393 yes no
` 5 Status 859 ----- yes yes
` 6 Timing Mark 860 ----- 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 yes no
` 23 Send Location 779 ----- yes no
` 24 Terminal Type 930 ----- yes no
` 25 End of Record 885 ----- yes no
` 26 TACACS User Identification 927 ----- yes no
` 27 Output Marking 933 ----- yes no
` 28 Terminal Location Number 946 ----- no no
` 255 Extended-Options-List 861 ----- yes yes
`
` The DHP column indicates if the specification is included in the
` DDN 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,
`
`Reynolds & Postel [Page 16]
`
`EX 1012 Page 16
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` Timing Mark, and Extended Options List options have been
` 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@ISI.EDU
`
` SUPDUP Protocol ------------------------------------------- (SUPDUP)
`
` STATUS: Elective
`
` SPECIFICATION: RFC 734 (in DPH)
`
` COMMENTS:
`
` A special Telnet like protocol for display terminals.
`
` OTHER REFERENCES:
`
` DEPENDENCIES: Transmission Control Protocol
`
` CONTACT: Crispin@SU-SCORE.STANFORD.EDU
`
` File Transfer Protocol --------------------------------------- (FTP)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 959 (in DPH)
`
` COMMENTS:
`
` The protocol for moving files between Internet hosts. Provides
` for access control and negotiation of file parameters.
`
` The following new optional commands are included in this
` edition of the specification: Change to Parent Directory
`
`Reynolds & Postel [Page 17]
`
`EX 1012 Page 17
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove
` Directory (RMD), Make Directory (MKD), Print Directory (PWD),
` and System (SYST). Note that this specification is compatible
` with the previous edition (RFC 765).
`
` A discrepancy has been found in the specification in the
` examples of Appendix II. On page 63, a response code of 200 is
` shown as the response to a CWD command. Under the list of
` Command-Reply Sequences cited on page 50, CWD is shown to only
` accept a 250 response code. Therefore, if one would interpret
` a CWD command as being excluded from the File System functional
` category, one may assume that the response code of 200 is
` correct, since CDUP as a special case of CWD does use 200.
`
` OTHER REFERENCES:
`
` RFC 678 (in DPH) - Document File Format Standards
`
` MIL-STD-1780 (in DPH) - File Transfer Protocol
`
` DEPENDENCIES: Transmission Control Protocol
`
` CONTACT: Postel@ISI.EDU
`
` Trivial File Transfer Protocol ------------------------------ (TFTP)
`
` STATUS: Elective
`
` SPECIFICATION: RFC 783 (in IPTW)
`
` COMMENTS:
`
` A very simple file moving protocol, no access control is
` provided.
`
` This is in use in several local networks.
`
` Ambiguities in the interpretation of several of the transfer
` modes should be clarified, and additional transfer modes could
` be defined. Additional error codes could be defined to more
` clearly identify problems.
`
` Note: The DPH contains IEN-133, which is an obsolete version of
` this protocol.
`
` OTHER REFERENCES:
`
`Reynolds & Postel [Page 18]
`
`EX 1012 Page 18
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` DEPENDENCIES: User Datagram Protocol
`
` CONTACT: Postel@ISI.EDU
`
` Simple File Transfer Protocol ------------------------------- (SFTP)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 913 (in DPH)
`
` COMMENTS:
`
` SFTP is a simple file transfer protocol. It fills the need of
` people wanting a protocol that is more useful than TFTP but
` easier to implement (and less powerful) than FTP. SFTP
` supports user access control, file transfers, directory
` listing, directory changing, file renaming and deleting.
`
` SFTP can be implemented with any reliable 8-bit byte stream
` oriented protocol, this document describes its TCP
` specification. SFTP uses only one TCP connection; whereas TFTP
` implements a connection over UDP, and FTP uses two TCP
` connections (one using the TELNET protocol).
`
` Please discuss any plans for implementation or use of this
` protocol with the contact.
`
` OTHER REFERENCES:
`
` DEPENDENCIES: Transmission Control Protocol
`
` CONTACT: MKL@SRI-NIC.ARPA
`
` Simple Mail Transfer Protocol ------------------------------- (SMTP)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 821 (in DPH)
`
` 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 19]
`
`EX 1012 Page 19
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` There have been many misunderstandings and errors in the early
` implementations. Some documentation of these problems can be
` found in the file [C.ISI.EDU]<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.
`
` Note: RFC 822 is not included in the DPH (an accident, it
` should have been).
`
` MIL-STD-1781 (in DPH) - Simple Mail Transfer Protocol (SMTP)
`
` DEPENDENCIES: Transmission Control Protocol
`
` CONTACT: Postel@ISI.EDU
`
` Network News Transfer Protocol ------------------------------ (NNTP)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 977
`
` COMMENTS:
`
` NNTP specifies a protocol for the distribution, inquiry,
` retrieval, and posting of news articles using a reliable
` stream-based transmission of news among the Internet community.
` NNTP is designed so that news articles are stored in a central
` database allowing a subscriber to select only those items he
` wishes to read. Indexing, cross-referencing, and expiration of
` aged messages are also provided.
`
` Please discuss any plans for implementation or use of this
` protocol with the contact.
`
` OTHER REFERENCES:
`
`Reynolds & Postel [Page 20]
`
`EX 1012 Page 20
`
`

`

`
`RFC 1011 - Official Internet Protocols May 1987
`
` DEPENDENCIES: Internet Protocol
`
` CONTACT: Brian@SDCSVAX.UCSD.EDU
`
` Post Office Protocol - Version 2 ---------------------------- (POP2)
`
` STATUS: Experimental
`
` SPECIFICATION: RFC 937 (in DPH)
`
` COMMENTS:
`
` The intent of the Post Office Protocol - Version 2 (POP2) is to
` allow a user’s workstation to access mail from a mailbox
` server. It is expected that mail will be posted from the
` workstation to the mailbox server via the Simple Mail Transfer
` Protocol (SMTP).
`
` Please discuss any plans for implementation or use of this
` protocol with the contact.
`
` OTHER REFERENCES: Obsoletes RFC 918
`
` DEPENDENCIES: Transmission Control Protocol
`
` CONTACT: JKReynolds@ISI.EDU
`
` NetBIOS Services Protocol -------------------------------- (NETBIOS)
`
` STATUS: Recommended
`
` SPECIFICATION: RFC 1001, 1002
`
` COMMENTS:
`
` These documents define a proposed standard protocol to support
` NetBIOS services in a TCP/IP environment. Both local network
` and internet operation are supported. Various node types are
` defined to accomodate local and internet topologies and to
` allow operation with or without the use of IP broadcast
`
` RFC 1001 describes t