rfc172.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


NWG/RFC 172


   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.

     Hex    Octal

      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 assignment

      4F     077

      5A     100

   through through                       Reserved for experimental use

      FF     377

3B.2 Requests and Identifiers

   Retrieve, delete, name_from, rename_t, and append requests contain a
   pathname, following the op code, in the information field. A pathname
   may also follow the opcode in list_file_directory request.

   A 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 (as
   defined in the TELNET protocol) shall be used.






                                                                [Page 7]

NWG/RFC 172


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

   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.

   Store request achieves the transfer of a copy of file specified in
   pathname, 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.

   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 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 in the using system. Such queries should not be
   transmitted over network connections.

   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 are normally sent at
   the start of connection.

3B.3 Error and Acknowledge Terminates

   The error transactions may have an error code indicated by the second
   descriptor byte. Transmission of an error message in text is also
   permitted. The following error codes are defined.











                                                                [Page 8]

NWG/RFC 172


     Error Code (2nd descriptor byte)           Meaning
    Hex    Octal

     00     000                 Error condition indicated by computer
                                system (external to protocol)

     01     001                 Name syntax error

     02     003                 Access control violation

     03     003                 Abort

     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                 Error described in text message
                                (ASCII characters follow code)

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 which transactions
    occur depends on the type of request, as described in section
    4B. The fulfilling of a request may be aborted anytime by either
    host, as explained in section 4C.

4B. Identifier transactions (change 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]

NWG/RFC 172


    Retrieve and list_file_directory requests 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.

          Read / List_file_directory request
         ------------------------------------->
    User            <File -- data>              Server
         <-------------------------------------
                End of file indication
         <-------------------------------------

    Store and append 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.

    User          Store / Append request        Server
         ------------------------------------->
                  <File -- data>
         ------------------------------------->
                  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_to request
         ------------------------------------->
                  Acknowledge
         <-------------------------------------

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

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

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




                                                               [Page 10]

NWG/RFC 172


4C. Aborts. Either host may abort a request fulfillment sequence at
    any time by sending an error terminate, or by closing the
    connection (NCP to transmit a CLS 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 or fulfill new requests. When CLS is used to
    abort, the using host will be responsible for reopening
    connection. The file transfer abort described here is different
    from the data transfer abort which is sent only by the sender of
    data. The use of the data transfer abort is not defined in this
    protocol.

6.  Initial Connection, CLS, and Access Control

6A. There will be a preassigned permanent socket number[6] for the
    cooperating file transfer process at the serving host. The
    connection establishment will be in accordance with the standard
    initial connection protocol[7], establishing a full-duplex
    connection.

6B. 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
    transaction 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.

6C. It is recommended that identifier (user name and password)
    transactions be sent by user to server , at the start, as this
    would facilitate default handling and access control for the
    entire duration of connection. The identifier transactions do not
    require or permit and 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, upon subsequent requests.

NOTES

[1] Alex McKenzie, BBN, is conducting a survey of network file systems
to determine the practicality of standard pathname conventions, and to
disseminate information to network users on host file systems.






                                                               [Page 11]

NWG/RFC 172


[2] This initial subset represents control functions necessary for basic
file transfer operations, and some elementary file manipulation
operations. There is no attempt to provide a data management or complete
file management capability.

[3] It is possible that we may, at a later date, assign meaning to these
information separators within FTP.

[4] A workable subset is any request, plus terminates. Identifiers may
be required in addition when using protected file systems.

[5] 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.

[6] It seems that socket 1 has been assigned to logger. Socket 3 seems a
reasonable choice for File Transfer.

[7] 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 Glenn Forbes Fleming Larratt 5/97 ]



























                                                               [Page 12]