rfc172.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页

Network Working Group                           23 June 1971
Request for Comments #172                       Abhay Bhushan, MIT
NIC 6794                                        Bob Braden, UCLA
Categories: D.4, D.5, and D.7                   Will Crowther, BBN
Updates: 114                                    Eric Harslem, Rand
Obsolete: None                                  John Heafner, Rand
                                                Alex McKenzie, BBN
                                                John Melvin, SRI
                                                Bob Sundberg, Harvard
                                                Dick Watson, SRI
                                                Jim White, UCSB












                    THE FILE TRANSFER PROTOCOL



























                                                                [Page 1]

NWG/RFC 172


I. INTRODUCTION

      The file transfer protocol (FTP) is a user-level protocol for file
transfer between host computers (including terminal IMP's), on the ARPA
computer network. The primary function of FTP is to facilitate transfer
of files between hosts, and to allow convenient use of storage and file
handling capabilities of other hosts. FTP uses the data transfer
protocol described in RFC 171 to achieve transfer of data. This paper
assumes knowledge of RFC 171.

      The objectives of FTP are to promote sharing of files (computer
programs and/or data), encourage indirect use (without login or
implicit) of computers, and shield the user from variations in file and
storage systems of different hosts, to the extent it is practical.
These objectives are achieved by specifying a standard file transfer
socket and initial connection protocol for indirect use, and using
standard conventions for file transfer and related operations.

II. DISCUSSION

      A file is considered here to be an ordered set of arbitrary
length, consisting of computer (including instructions) data. Files are
uniquely identified in a system by their pathnames. A pathname is
(loosely) defined to be the data string which must be input to the file
system by a network user in order to identify a file. Pathname usually
contains device and/or directory names, and file names in case of named
files. FTP specifications provide standard file system commands, but do
not provide standard naming convention at this time.  Each user must
follow the naming convention of the file system he wishes to use. FTP
may be extended later to include standard conventions for pathname
structures.[1]

      A file may or may not have access controls associated with it.
The access controls designate the users' access privilege. In the
absence of access controls, the files cannot be protected from
accidental or unauthorized usage. It is the prerogative of a resident
file system to provide protection, and selective access. FTP only
provides identifier and password mechanisms for exchange of access
control information. It should however be noted, that for file sharing,
it is necessary that a user be allowed (subject to access controls) to
access files not created by him.

      FTP does not restrict the nature of information in the file. For
example, a file could contain ASCII text, binary data computer program,
or any other information. A provision for indicating data structure
(type and byte size) exists in FTP to aid in parsing, interpretation,
reconfiguration, and storage of data. To facilitate indirect usage, the
cooperating file transfer processes may be disowned "daemon" processes



                                                                [Page 2]

NWG/RFC 172


which "listen" to agreed-upon sockets, and follow the standard initial
connection protocol for establishing a full-duplex connection. It should
be noted that FTP could also used directly by logging into a remote
host, and arranging for file transfer over specific sockets.

      FTP is readily extensible, in that additional commands and data
types may be defined by those agreeing to implement them.
Implementation of a subset of commands is specifically permitted, and an
initial subset for implementation is recommended.[2] The protocol may
also be extended to enable remote execution of programs, but no standard
procedure is suggested.

      For transferring data, FTP uses the data transfer protocol
specified in RFC 171. As the data transfer protocol does not specify the
manner in which it is to be used by FTP, implementation may vary at
different host sites. Hosts not wishing to separate the data transfer
and file transfer functions, should take particular care in conforming
to the data transfer protocol specifications of RFC 171.

      It should be noted, that FTP specifications do not require
knowledge of transfer modes used by data transfer protocol. However, as
file transfer protocol requires the transfer of more than a single
control transaction over the same connection, it is essential that hosts
be able to send control transactions in either 'transparent block' (type
B9) of 'descriptor and counts' (type BA) modes. (Type BB, the indefinite
bit stream mode is not suitable as it limits transfer to singles
transactions.).

      The use of data transfer aborts (type B6) is neither required, nor
defined in FTP. FTP has its own error terminate which may be used to
abort a file transfer request. FTP also does not define the structure of
files, and there are no conventions on the use of group, record and unit
separators.[3] A file separator is, however, used to indicate the end of
file. It is strongly recommended that default options be provided in
implementation to facilitate use of file transfer service. For example,
the main file directory on disk, a pool directory, user directory or
directory last accessed could serve as standard pathname defaults.
Default mechanisms are convenient, as the user doesn't have to specify
the complete pathname each time he wishes to use the file transfer
service.

III. SPECIFICATIONS

1.  Data Transfer

   FTP uses the data transfer protocol described in RFC 171, for
   transferring data and/or control transaction. Both data and control
   transactions are communicated over the same connection.



                                                                [Page 3]

NWG/RFC 172


2.  Data Transactions

   Data transactions represent the data contained in a file. There is no
   data type or byte size information contained in data transactions.
   The structure of data is instead communicated via control
   transactions. A file may be transferred as one or more data
   transactions. The protocol neither specifies nor imposes any
   limitations on the structure (record, group, etc) or length of file.
   Such limitations may however be imposed by a serving host. The end of
   a file may be indicated either by a file separator (as defined in
   data transfer protocol), or by closing connection (in type B0). In
   particular a serving or using host should not send the ETX, or other
   end of file character, unless such a character is part of the data in
   file (i.e., not provided by system).

3.  Control Transactions

   The control transactions may be typified as requests, identifiers,
   and terminates.  A request fulfillment sequence begins with a request
   and ends with receipt of data (followed by End-of-File) or a
   terminate.

3A. Op Codes

   Control transactions are distinguished by their first byte referred
   as op code. A standard set of opcodes is defined below.
   Implementation of a workable[4] subset of opcodes is specifically
   permitted. Additional standard opcodes may be assigned later. Opcodes
   hex 5A (octal 100) through hex FF (octal 377) are for experimental
   use.





















                                                                [Page 4]

NWG/RFC 172


       Op Code                   Operation
     Hex    Octal

      00     000         Change data type identifier

      01     001         Retrieve Request

      02     002         Store request (replaced if file already
                         exists)

      03     003         Delete request

      04     004         Rename_from request

      05     005         Rename_to request

      06     006         List_file_directory request

      07     007         Username identifier

      08     010         Password identifier

      09     011         Error or unsuccessful terminate

      04     012         Acknowledge or successful terminate

      0B     013         Append request (add to existing file)


      0C     014

   through through       Reserved for standard assignment

      4F     077


      5A     100

   through through       Reserved for experimental use

      FF     377










                                                                [Page 5]

NWG/RFC 172


3B. Syntax and Semantics

3B.1 Data Types

   The 'change data type' control transactions identifies the structure
   of data (data type and byte size) in succeeding data transactions.
   This transaction shall contain two more bytes in addition to the
   opcode byte. The first of these bytes shall convey a data type or
   code information and the second byte may convey the data byte size,
   where applicable. This information may be used to define the manner
   in which data is to be parsed, interpreted, reconfigured or stored.
   Change data type need be sent only when structure of data is changed
   from the preceding.

   Although, a number of data types are defined, specific
   implementations may handle only limited data types or completely
   ignore the data type and byte size descriptors. Even if a host
   process does not "recognize" a data type, it must accept data (i.e.,
   there is no such thing as a data type error.) These descriptors are
   provided only for convenience, and it is not essential that they be
   used. The standard default is to assume nothing about the information
   and treat it as a bit stream (binary data, byte size 1)[5] whose
   interpretation is left to a higher level process, or the user.

   _________________________
   * It is, however, possible that this bit stream is treated like
   ASCII characters in specific instances such as transmitting a file
   to a line printer.























                                                                [Page 6]