rfc924.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 2,031 行 · 第 1/4 页
TXT
2,031 行
DEPENDENCIES: Internet Protocol
CONTACT: Brescia@BBN-UNIX.ARPA
Reynolds & Postel [Page 9]
Official ARPA-Internet Protocols RFC 924
Multiplexing Protocol ---------------------------------------- (MUX)
STATUS: Experimental
SPECIFICATION: IEN 90
COMMENTS:
Defines a capability to combine several segments from different
higher level protocols in one IP datagram.
No current experiment in progress. There is some question as
to the extent to which the sharing this protocol envisions can
actually take place. Also, there are some issues about the
information captured in the multiplexing header being (a)
insufficient, or (b) over specific.
Please discuss any plans for implementation or use of this
protocol with the contact.
OTHER REFERENCES:
DEPENDENCIES: Internet Protocol
CONTACT: Postel@USC-ISIF.ARPA
Stream Protocol ----------------------------------------------- (ST)
STATUS: Experimental
SPECIFICATION: IEN 119
COMMENTS:
A gateway resource allocation protocol designed for use in
multihost real time applications.
The implementation of this protocol has evolved and may no
longer be consistent with this specification. The document
should be updated and issued as an RFC.
Please discuss any plans for implementation or use of this
protocol with the contact.
OTHER REFERENCES:
DEPENDENCIES: Internet Protocol
CONTACT: jwf@LL-EN.ARPA
Reynolds & Postel [Page 10]
Official ARPA-Internet Protocols RFC 924
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
DEPENDENCIES: Internet Protocol, Stream Protocol
CONTACT: Casner@USC-ISIB.ARPA
Reliable Data Protocol --------------------------------------- (RDP)
STATUS: Experimental
SPECIFICATION: RFC 908
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.
OTHER REFERENCES:
DEPENDENCIES: Internet Protocol
CONTACT: CWelles@BBN-UNIX.ARPA
Reynolds & Postel [Page 11]
Official ARPA-Internet Protocols RFC 924
APPLICATION LEVEL
Telnet Protocol ------------------------------------------- (TELNET)
STATUS: Recommended
SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and
Options")
COMMENTS:
The protocol for remote terminal access.
This has been revised since the IPTW. RFC 764 in IPTW is now
obsolete.
OTHER REFERENCES:
MIL-STD-1782 - Telnet Protocol and Options (TELNET)
DEPENDENCIES: Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 12]
Official ARPA-Internet Protocols RFC 924
Telnet Options ------------------------------------ (TELNET-OPTIONS)
STATUS: Elective
SPECIFICATION: General description of options: RFC 855
(in "Internet Telnet Protocol and Options")
Number Name RFC NIC ITP APH USE
------ --------------------------------- --- ----- --- --- ---
0 Binary Transmission 856 ----- yes obs yes
1 Echo 857 ----- yes obs yes
2 Reconnection ... 15391 no yes no
3 Suppress Go Ahead 858 ----- yes obs yes
4 Approx Message Size Negotiation ... 15393 no yes no
5 Status 859 ----- yes obs yes
6 Timing Mark 860 ----- yes obs yes
7 Remote Controlled Trans and Echo 726 39237 no yes no
8 Output Line Width ... 20196 no yes no
9 Output Page Size ... 20197 no yes no
10 Output Carriage-Return Disposition 652 31155 no yes no
11 Output Horizontal Tabstops 653 31156 no yes no
12 Output Horizontal Tab Disposition 654 31157 no yes no
13 Output Formfeed Disposition 655 31158 no yes no
14 Output Vertical Tabstops 656 31159 no yes no
15 Output Vertical Tab Disposition 657 31160 no yes no
16 Output Linefeed Disposition 658 31161 no yes no
17 Extended ASCII 698 32964 no yes no
18 Logout 727 40025 no yes no
19 Byte Macro 735 42083 no yes no
20 Data Entry Terminal 732 41762 no yes no
21 SUPDUP 734 736 42213 no yes no
22 SUPDUP Output 749 45449 no no no
23 Send Location 779 ----- no no no
24 Terminal Type 884 ----- no no yes
25 End of Record 885 ----- no no yes
255 Extended-Options-List 861 ----- yes obs yes
(obs = obsolete)
The ITP column indicates if the specification is included in the
Internet Telnet Protocol and Options. The APH column indicates if
the specification is included in the ARPANET Protocol Handbook.
The USE column of the table above indicates which options are in
general use.
COMMENTS:
The Binary Transmission, Echo, Suppress Go Ahead, Status,
Timing Mark, and Extended Options List options have been
Reynolds & Postel [Page 13]
Official ARPA-Internet Protocols RFC 924
recently updated and reissued. These are the most frequently
implemented options.
The remaining options should be reviewed and the useful ones
should be revised and reissued. The others should be
eliminated.
The following are recommended: Binary Transmission, Echo,
Suppress Go Ahead, Status, Timing Mark, and Extended Options
List.
OTHER REFERENCES:
DEPENDENCIES: Telnet
CONTACT: Postel@USC-ISIF.ARPA
File Transfer Protocol --------------------------------------- (FTP)
STATUS: Recommended
SPECIFICATION: RFC 765 (in IPTW)
COMMENTS:
The protocol for moving files between Internet hosts. Provides
for access control and negotiation of file parameters.
There are a number of minor corrections to be made. A major
change is the deletion of the mail commands, and a major
clarification is needed in the discussion of the management of
the data connection. Also, a suggestion has been made to
include some directory manipulation commands (RFC 775).
Even though the MAIL features are defined in this document,
they are not to be used. The SMTP protocol is to be used for
all mail service in the Internet.
Data Connection Management:
a. Default Data Connection Ports: All FTP implementations
must support use of the default data connection ports, and
only the User-PI may initiate the use of non-default ports.
b. Negotiating Non-Default Data Ports: The User-PI may
specify a non-default user side data port with the PORT
command. The User-PI may request the server side to
identify a non-default server side data port with the PASV
command. Since a connection is defined by the pair of
Reynolds & Postel [Page 14]
Official ARPA-Internet Protocols RFC 924
addresses, either of these actions is enough to get a
different data connection, still it is permitted to do both
commands to use new ports on both ends of the data
connection.
c. Reuse of the Data Connection: When using the stream
mode of data transfer the end of the file must be indicated
by closing the connection. This causes a problem if
multiple files are to be transfered in the session, due to
need for TCP to hold the connection record for a time out
period to guarantee the reliable communication. Thus the
connection can not be reopened at once.
There are two solutions to this problem. The first is to
negotiate a non-default port (as in (b) above). The
second is to use another transfer mode.
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer
modes (Block, Compressed) do not close the connection to
indicate the end of file. They have enough FTP encoding
that the data connection can be parsed to determine the
end of the file. Thus using these modes one can leave
the data connection open for multiple file transfers.
Why this was not a problem with the old NCP FTP:
The NCP was designed with only the ARPANET in mind.
The ARPANET provides very reliable service, and the
NCP counted on it. If any packet of data from an NCP
connection were lost or damaged by the network the NCP
could not recover. It is a tribute to the ARPANET
designers that the NCP FTP worked so well.
The TCP is designed to provide reliable connections
over many different types of networks and
interconnections of networks. TCP must cope with a
set of networks that can not promise to work as well
as the ARPANET. TCP must make its own provisions for
end-to-end recovery from lost or damaged packets.
This leads to the need for the connection phase-down
time-out. The NCP never had to deal with
acknowledgements or retransmissions or many other
things the TCP must do to make connection reliable in
a more complex world.
Reynolds & Postel [Page 15]
Official ARPA-Internet Protocols RFC 924
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
MIL-STD-1780 - File Transfer Protocol (FTP)
DEPENDENCIES: Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Trivial File Transfer Protocol ------------------------------ (TFTP)
STATUS: Elective
SPECIFICATION: RFC 783 (in IPTW)
COMMENTS:
A very simple file moving protocol, no access control is
provided.
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.
OTHER REFERENCES:
DEPENDENCIES: User Datagram Protocol
CONTACT: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 16]
Official ARPA-Internet Protocols RFC 924
Simple File Transfer Protocol ------------------------------- (SFTP)
STATUS: Experimental
SPECIFICATION: RFC 913
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@MIT-XX.ARPA
Simple Mail Transfer Protocol ------------------------------- (SMTP)
STATUS: Recommended
SPECIFICATION: RFC 821 (in "Internet Mail Protocols")
COMMENTS:
The procedure for transmitting computer mail between hosts.
This has been revised since the IPTW, it is in the "Internet
Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is
obsolete.
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.
Some minor differences between RFC 821 and RFC 822 should be
resolved.
Reynolds & Postel [Page 17]
Official ARPA-Internet Protocols RFC 924
OTHER REFERENCES:
RFC 822 - Mail Header Format Standards
This has been revised since the IPTW, it is in the "Internet
Mail Protocols" volume of November 1982. RFC 733 (in IPTW)
is obsolete. Further revision of RFC 822 is needed to
correct some minor errors in the details of the
specification.
MIL-STD-1781 - Simple Mail Transfer Protocol (SMTP)
DEPENDENCIES: Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Resource Location Protocol ----------------------------------- (RLP)
STATUS: Elective
SPECIFICATION: RFC 887
COMMENTS:
A resource location protocol for use in the ARPA-Internet.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?