rfc454.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,488 行 · 第 1/5 页
TXT
1,488 行
Network Working Group A. McKenzie
Request for Comments: 454 BBN
NIC: 14333 16 February 1973
FILE TRANSFER PROTOCOL
Meeting Announcement and a New Proposed Document
Attached is a new proposal for a File Transfer Protocol. The
document is an extensive update to RFC 354 and, I believe,
incorporates solutions to most of the objections to RFC 354.
It now seems appropriate to make another attempt to reach final
agreement on FTP. Accordingly, I am calling a meeting of interested
parties, to be held at BBN on March 16, for discussion of this and
other proposals.
This note is directed to the network community at large, rather than
specifically to the old FTP committee, because I don't believe that
the FTP committee membership includes all the individuals who have
contributed to the current state of FTP design. Nevertheless, it is
intended that the meeting proceed from the current state, rather than
bringing new members up-to-speed. Prospective attendees should
therefore be familiar with at least the following documents:
RFC 354
RFC 385
RFC 414
RFC 418
RFC 438
Anyone wishing to attend this meeting should contact Alex McKenzie
(NIC Ident aam) at BBN, 50 Moulton Street, Cambridge, Mass. 02138.
My telephone number is:
(617) 491-1850 ext.441
When there is some indication of the number of individuals planning
to attend, a meeting room will be reserved and more specific
information will be directed to attendees.
McKenzie [Page 1]
RFC 454 File Transfer Protocol July 1972
PROPOSED FILE TRANSFER PROTOCOL
This document is the outcome of a meeting held 25 January 1973 in
Cambridge, Massachusetts, by the following people:
Abhay Bhushan (MIT - DMCG)
Bob Bressler (BBN - NET)
Bob Clements (BBN - TENEX)
Alex McKenzie (BBN - NET)
Nancy Neigus (BBN - NET)
Ken Pogran (MIT - MULTICS)
Marc Seriff (MIT - DMCG)
The basis of the document is RFC 354 with considerations drawn from
RFC's 385, 414, 418, and 438 and personal communication with network
participants.
McKenzie [Page 2]
RFC 454 File Transfer Protocol July 1972
PROPOSED FILE TRANSFER PROTOCOL
INTRODUCTION
The File Transfer Protocol (FTP) is a protocol for file transfer
between HOSTs (including terminal IMPs), on the ARPA Computer Network
(ARPANET). The primary function of FTP is to transfer files
efficiently and reliably among HOSTs and to allow the convenient use
of remote file storage capabilities.
The objectives of FTP are 1) to promote sharing of files (computer
programs and/or data), 2) to encourage indirect or implicit (via
programs) use of remote computers, 3) to shield a user from
variations in file storage systems among HOSTs, and 4) to transfer
data reliably and efficiently. FTP, though usable directly by a user
at a terminal, is designed mainly for use by programs.
The attempt in this specification is to satisfy the diverse needs of
users of maxi-HOSTs, mini-HOSTs, TIPs, and the Datacomputer, with a
simple, elegant, and easily implemented protocol design.
This paper assumes knowledge of the following protocols:
1) The HOST-HOST Protocol (NIC #8246)
2) The Initial Connection Protocol (NIC #7101)
3) The TELNET Protocol (NWG/RFC #318, NIC #9348)
II. DISCUSSION
In this section, the terminology and the FTP model are discussed.
The terms defined in this section are only those that have special
significance in FTP.
II.A Terminology
ASCII The USASCII character set as defined in NIC
#7104. In FTP, ASCII characters are defined to
be the lower half of an eight bit code set (i.e.,
the most significant bit is zero).
access controls Access controls define users' access privileges
to the use of a system, and to the files in that
system. Access controls are necessary to prevent
unauthorized or accidental use of files. It is
the prerogative of a server-FTP process to
provide access controls.
McKenzie [Page 3]
RFC 454 File Transfer Protocol July 1972
byte size The byte size specified for the transfer od data.
The data connection is opened with this byte
size. Data connection byte size is not
necessarily the byte size in which data is to be
stored in a system, and may not be related to the
structure of data.
data connection A simplex connection over which data is
transferred, in a specified byte size, mode and
type. The data transferred may be a part of a
file, an entire file or a number of files. The
data connection may be in either direction
(server-to-user or user-to-server).
data socket The socket on which a User-FTP process "listens"
for a data connection.
EOF The end-of-file condition that defines the end of
a file being transferred.
EOR The end-of-record condition that defines the end
of a record being transferred.
error recovery A procedure that allows a user to recover from
certain errors such as failure of either HOST
system or transfer process. In FTP, error
recovery may involve restarting a file transfer
at a given checkpoint.
FTP commands A set of commands that comprise the control
information flowing from the user-FTP to the
server-FTP process.
file An ordered set of computer data (including
programs) of arbitrary length uniquely identified
by a pathname.
mode The mode in which data is to be transferred via
the data connection. The mode defines the data
format including EOR and EOF. The transfer modes
defined in FTP are described in Section III.C.
NVT The Network Virtual Terminal as defined in the
ARPANET TELNET Protocol.
McKenzie [Page 4]
RFC 454 File Transfer Protocol July 1972
NVFS The Network Virtual File System. A concept which
defines a standard network file system with
standard commands and pathname conventions. FTP
only partially embraces the NVFS concept at this
time.
pathname Pathname is defined to be the character string
which must be input to a file system by a user in
order to identify a file. Pathname normally
contains device and/or directory names, and file
name specification. FTP does not yet specify a
standard pathname convention. Each user must
follow the file naming conventions of the file
systems he wishes to use.
record A sequential file may be structured as a number
of contiguous parts called records. Record
structures are supported by FTP but are not
mandatory.
reply A reply is an acknowledgement (positive or
negative) sent from server to user via the TELNET
connections in response to FTP commands. The
general form of a reply is a completion code
(including error codes) followed by an ASCII text
string. The codes are for use by programs and
the text is for human users.
server-FTP process A process or set of processes which perform the
function of file transfer in cooperation with a
user-FTP process. The server-FTP process must
interpret and respond to user commands and
initiate the data connection.
server site A HOST site which has a server-FTP process.
server-TELNET A TELNET process which listens on a specified
socket for an ICP initiated by a user-TELNET, and
performs in accordance with the ARPANET TELNET
Protocol.
TELNET connections The full-duplex communication path between a
user-TELNET and a server-TELNET. The TELNET
connections are established via the standard
ARPANET Initial Connection Protocol (ICP).
McKenzie [Page 5]
RFC 454 File Transfer Protocol July 1972
type The data representation type used for data
transfer and storage. Type implies certain
transformations between the time of data storage
and data transfer. The representation types
defined in FTP are described in Section III.B.
user A process on behalf of a human being or a human
being wishing to obtain file transfer service.
user site A HOST site satisfying any of the following
conditions: 1) The site where a user is located,
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?