rfc265.txt

RFC 的详细文档！

Network Working Group                             17 November 1971
Request for Comments #265                         Abbay Bhushan, MIT
NIC 781                                           Bob Braden, UCLA
Categories D.4, D.5, and D.7                      Will Crowther, BBN
                                                  Eric Narslem, Rand
Obsoletes: 172                                    John Heafner, Rand
                                                  Alex McKenzie, BBH
                                                  John Melvin, SRI
                                                  Bob Sundberg, Harvard
                                                  Dick Watson, SRI
                                                  Jim White, UOSB


                       THE FILE TRANSFER PROTOCOL

    This Paper is a revision of RF 172, Mic 6794. The changes
to RFC 172 are given below. The protocol is then restated for
your ocnvenience.

                           CHANGES TO RFC 172

1) Two new file transfer requests have been added. These are

2) The op code assignements in control transactions have been
changed to include the above requests.

3) Two new error codes indicating 'incorrect or missing
indentifier' and 'file already exists' have been added. New error
code assignements reflect this change.

4) Editorial changes to clarify specifications.




















                                                                [Page 1]

File Transfer Protocol          RFC 265                 17 November 1971


I. INTRODUCTION

    The file transfer protocol (FTP) is a userlevel procotocol for
file transfer between host computers (including terminal IMPs), on the
ARPA computer network (ARPANET). 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 remote hosts. FTP uses
the Data Transfer Protocol described in RFC 264 to achieve transfer of
data. This paper assumes knowledge of RFC 264.

    The objectives of FTP are to promote sharing of files (computer
programs and/or data) encourage implicit (without explicit login) use
of computers, and shield the user from variations in file and storage
systems of different hosts. These objetives are achieved by specifying
a standard file transfer socket and initial connection protocol for
implicit 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 data (including programs). 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 name. 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 be wishing to use. FTP may be
extended later to include standard conventions of pathname structures.

    A file may or may not have access control associated with it The
access controls designate users access privileges. In absence of
access controls, files cannot be protected from accidental or
unauthorized usage. It is the prerogative of a serving file system to
provide protection, and selective access.  FTP provides identifier and
password mechanisms for exchange of access control information. it
should however ve 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 files.  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, and storage of data.





                                                                [Page 2]

File Transfer Protocol          RFC 265                 17 November 1971


    To facilitate impliict usage, a serving file transfer process my
be a disowned "demon" process which "listens" to an agreed-upon
socket, and follows the standard initial connection protocol for
establishing a fill-duplex connection. It should be noted that FTP my
also be used directly by logging into a remote host, and arranging for
file transfer over specific sockets.

    FTP is readily extendable, 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. (*)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 264. As the data transfer protool 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 data transfer
and file transfer functions, should take particular care in conforming
to the data transfer protocol specifications of RFC 264.

    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) or 'descriptor and counts' (type BA) modes. (Type BS,
the indefinite bit stream mode is not suitable as it limits transfer
to single transactions.).

    The use of data transfer aborts (type B6) is neither required, nor
defined in FTP. FTP has its own error terminate wich may be used to
abort a file transfer request. FTP also does not define to structure
of files, and there are no conventions on the use of group, record and
unit separators. (*)A file separator however, indicates the end of a
file.

    It is strongly recommended that default options be provided in
implementation to facilitate use of file transfer service.  For
example, the main file directora on disk, a pool directory, user
directory of diretory 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 ve wishes to use the file
transfer service. No standard default procedures are specified by FTP.

--------------------------------
(*)
    This initial subset represents control functions necessary for



                                                                [Page 3]

File Transfer Protocol          RFC 265                 17 November 1971


basic file transfer and "mail" operations, and some elementary file
manipulation operations. There is no attempt to provide a data
management or complete file management cpability.
(*)
    It is possible that wi may, at a later date, assign meaning to
these information separators within FTP.

III. SPECIFICATIONS

1.  Data Transfer

    FTP uses the Data Transfer Protocol (described in RFC 264)
    for transferring data and/or control transaction. Both data
    and control transactions are communicated over the same
    connection.

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 communicated via
    control transactions. A file may be transferred as one or
    more data transactions. The protocol neither specifies nor
    impose 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 by a
    file separator (as defined in data transfer protocol). In
    the special case of indefinite bit-stream transfer mode (Type
    B0), the end of file is indicated by closing connection. In
    particular, a serving or usin 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. The user side initiates the
    connections as well as the request. The server side "listens"
    and complies with the request.

3A. Op Codes

    The first information (i.e., not descriptor) byte or control
    transactions indicates the control function. This byte is
    referred to as "opcode". A standard set of opcodes are
    defined below. The operations are discussed in Section 2B.2.



                                                                [Page 4]

File Transfer Protocol          RFC 265                 17 November 1971


    Implementation of a workable 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.

     Op Code                          Operation
    Hex   Octal

    00    000                  Set data type identifier

    01    001                  Retrieve Request

    02    002                  Create request (write file; error ir
                               file already exits)

    03    003                  Store request (write file; replace
                               if file already exists)

    04    004                  Append request (add to existing file;
                               error if file does not exist)

    05    005                  Append_with_create request (add to
                               file; create if file does not exist)

    06    006                  Delete request (delete file)

    07    007                  Rename_from request (change file name)

    08    010                  Rename_to request (the new file name)

    09    011                  List request (list information)

    0A    012                  Username identifier (for access control)

    0B    013                  Password identifier (for access control)

    0C    014                  Error of unsuccessful terminate

    0D    015                  Acknowledge or successful terminate

    0E    016
through  through               Reserved for standard assignment
    4F    077

    5A    100
through  through               Assigned for experimental use
    FF    377




                                                                [Page 5]

File Transfer Protocol          RFC 265                 17 November 1971


------------------------------------
(*)
    A workable subset is any request, plus terminates.  Indentifiers
may be required in addition for usin "protected" file systems.

3B. Syntax and Semantics

3B.1 Data Types

    The 'set data type' control transactions indentifies the structure
    of data (data type and byte size) is succeeding data transactions.
    The 'set data type' 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. Set 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 data type error.) These descriptors are
    provided only for convenience, and it es 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)(*)whose interpretation is left to a higher level process, or the
    user.

    The following data type codes are currently assigned. Where a byte
    size is not implicit in data type, it may be provided by the second
    byte.

-----------------------------------
    (*)
   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]