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