rfc265.txt

中、英文RFC文档大全打包下载完全版 .


File Transfer Protocol          RFC 265                 17 November 1971


      Code          Implicit          Data Type
  Hex    Octal      Byte Size

  00     000           1             Bit stream (standard default)

  01     001         none            Binary data bytes

  02     002           8             Network ASCII characters

  03     003           8             EBCDIC characters

  04     004          36             DEC-packed ASCII (five 7-bit
                                     characters, 36th bit 1 or 0)

  05     005           8             Decimal numbers, net. ASCII

  06     006           8             Octal numbers, net. ASCII

  07     007           8             Hexadecimal numbers, net. ASCII

  08     010
through  through                     Reserved for standard assignemt
  4f     077

  5A     100
through  through                     Assigned for experimental use
  FF     377

3B.2 Requests and Identifiers

    Retrieve, create, append, append_with_create, delete, rename_from,
    and rename_to requests must contain a pathname specifying a file,
    following the opcode in the information field. In the list request a
    pathname may or may not follow the opcode. If present, the pathname
    may specify either a file or a directory.

    A file pathname must uniquely identify a file in the serving host.
    The syntax of pathnames and identifying information shall conform to
    serving host conventions, except that standard network ASCII (7-bit
    ASCII right justified in 8-bit) field with most signifcant bit as
    zero) shall be used.

    The store request has a 4-byte (32 bits) 'allocate size' field
    followed by a pathname specifying a file. 'Allocate size' indicates
    the number of bits of storage to be allocated to the file. An
    allocate size of zero indicates that server should use his default.





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


    Retrieve request achieves the transfer of a copy of file specified
    in pathname, from serving to using host. the status and contents of
    file in serving host should be unaffected.

    Create request causes a file to be created at the serving host as
    specified in pathname,  A copy of the file is transferred from the
    using to the serving host. If the file specified in pathname already
    exists at the serving host, an error terminate should be sent by the
    server.

    Store request achieves the transfer of copy of file from using to
    serving host. If file specified in pathname exists on serving hosts,
    then its contents shall be replaced by the contents of the file
    being transferred. A new file is created at the serving host if the
    file specified in pathname does not exist.

    Append request achieves the transfer of data from using to serving
    host. The transferred data is appended to file specified in
    pathname, at serving host. If the specified file does not exist at
    serving host, an error terminate should be sent by the server.

    Append with create request achieves the transfer of data from using
    to serving host. If file specified is pathname exists at serving
    host, then the transferred data is appended to that file, otherwise
    the file specified in pathname is created at the serving host.

    Rename from and rename to requests cause the name of the file
    specified in pathname of rename_from to be changed to the name
    specified in pathname of rename_to. A rename_from request must
    always be followed by a rename_to request.

    Delete request causes file specified in pathname to be deleted from
    the serving host. If an extra level of protection is desired such as
    the query "Do you really wish to delete this file?", it is to be a
    local implementation option in the using system. Such queries should
    not be transmitted over network connections.

    List request causes a list to be sent from the serving to using
    host. If there is no pathname of if pathname is a directory, the
    server should send a file directory list. If the pathname specifies
    a file then server should send current information on the file.

    Username and password identifiers contain the respective identifying
    information. Normally, the information will be supplied by the user
    of the file transfer service. These identifiers will normally be
    sent at the start of connetion for access control.





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


3B.3  Error and Acknowledge Terminates

    The error transactions may have an error code indicated by the
    second information byte. Transmission of an ASCII error message in
    subsequent bytes is permitted with all error codes, except that with
    Hex '0A' error code, ASCII text is required. The errors here relate
    to file transfer functions only. Data synchronization and related
    errors in data transfer are to be handled at the DTP level. The
    following error codes are currently defined:

    Error Code (2nd descriptor byte)      Meaning
   Hex     Octal
   00      000                Error condition indicated by
                              computer system (external to protocol)
   01      001                Name syntay error
   02      002                Access control violation
   03      003                Abort (by user)
   04      004                Allocate size too big
   05      005                Allocate size overflow
   06      006                Improper order for transactions
   07      007                Opcode not implemented
   08      010                File search failed
   09      011                Incorrect or missing identifier
   0A      012                Error described in text message
                              (ASCII characters follow code)
   0B      013                File already exists (in create request)

    At present, no completion codes are defined for acknowledge,
    It is assumed that acknowledge refers to the current request
    being fulfilled.

4.  Order of transactions

4A. A certain order of transactions must be maintained in
    fulfilling file transfer requests. The exact sequence in
    wich transactions occur depends on the type of request, as
    described in action 4B. The fullfillment of a request may be
    aborted anytime by either host, as explained in section 4C.

4B. Identifier transactions (set data type, username, and
    password) may be sent by user at any time. The usual order
    would be a username transaction followed by a password
    transaction at the start of the connection. No acknowledge
    is required, or permitted. The identifiers are to be used
    for default handling, and access control.






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


    Retrieve and list requests cause cause the transfer of file from
    server to user. After a complete file has been transferred, the
    server should indicate end-of-file (by sending CLS or file
    separator) to complete the request fulfillment sequence, as shown
    below.

                    Retrieve / List requests
                  ----------------------------->

    User                 < File -- Data>            Server
                  <-----------------------------
                    End of file indication
                  <-----------------------------

    Store, create, append, and append_with_create requests cause
    the transfer of file from user to server. After a complete
    file has been transferred, the user should send an
    end-of-file indication. The receipt of the file must be
    acknowledged by the server, as shown below.

           Create / Store / Append / Append_with_create requests
                  ----------------------------->
    User                 <File --- Data>            Server
                  ----------------------------->
                   End of file indication
                  ----------------------------->
                    Acknowledge
                  <-----------------------------

    Rename_from request must be followed by a rename_to request.
    The request must be acknowledged as shown below.

    User              Rename_from request           Server
                  ----------------------------->
                      Rename_ro request
                  ----------------------------->
                      Acknowledge
                  <-----------------------------

    The delete request requires the server to acknowledge it, as
    shown below.










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


    User                   Delete                   Server
                  ----------------------------->
                      Acknowledge
                  <-----------------------------

    Error transactions my be sent by either host at any time,
    and these terminate the current request fulfillment sequence.

4C. Aborts. Eithe host may abort a request fulfillment sequence
    at any time by sending an error terminate, or by closing the
    connection (NCP to transmit a CCLS for the connection). CLS
    is a more drastic type of abort and shall be used when there
    is a catastrophic failure, or when abort is desired in the
    middle of a long transaction. The abort indicates to the
    receiving host that sender of abort wishes to terminate
    request fulfillment and is now ready to initiate ar fulfill
    new requests. When CLS is used to abort, the using host will
    he responsible for reopening connection. The file transfer
    abort described here is different form data transfer
    abort which is sent only by the sender of data. The use of
    the data transfer is not defined in this protocol.

5.  Initial Connection, CLS, and Access Control

5A. Socket 3 is the standard preassigned socket number on which
    the cooperating file transfer process at the serving host
    should "listen". (*)The connection establishment will be in
    accordance with the standard initial connection
    protocol, (*)establishing a full-duplex connection.

5B. The connection will be broken by trading a CLS between the
    NCP's for each of the two connections. Normally, the user
    will initiate CLS.

    CLS may also be used by either user or server, to abort a
    transation in the middle. If CLS is received in the middle
    of transaction, the current request fulfillment sequence will
    be aborted. The using host will then reopen connection.

5C. It is recommended that identifier (user name and password)
    transactions be sent by user to server, at the start, as this
    would facilitate default handline and access control for the
    entire duration of connection. Some service sites may
    require the indentifier transactions. The identifier
    transactions do not require or permit an acknowledge, and the
    user can proceed directly with requests. If the identifier
    information is incorrect or not received, the server may send
    an error transaction indicating access control, violation,



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


    upon subsequent requests.

    ---------------------------------
    (*)
       Socket 1 has been assigned to logger, socket 3 seems a
    reasonable choice for File Transfer.

    (*)
       RFC 165, or any subsequent standard applicable in initial
    connection to loggers.

         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Gottfried Janik 7/97 ]






































                                                               [Page 12]