rfc880.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,509 行 · 第 1/3 页
TXT
1,509 行
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?