rfc114.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 956 行 · 第 1/3 页

         <char> ::= All 8-bit ASCII or EBCDIC characters except

                 US, RS, GS, FS, DC1, DC2, AND DC3.

         <filenames> ::= <name>|<filenames> RS <name>

         The data type for the request transaction shall be either A
         (octal 101 for ASCII, or E (octal 105) for EBCDIC [11].

         Some examples of pathname are:

         DC1 MT08
         DC1 DSK 1.2 US Net<3> US J.Doe US Foo
         udd US proj. US h,n/x US user US file
         filename 1 filename 2



Bhushan                                                         [Page 6]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   2B.2  Responses

         The response transactions shall normally have an empty data
         field.

   2B.3  Transfers

         The data types defined in section 4 will govern the syntax of
         the data field in transfer transactions.  No other syntactical
         restrictions exist.

   2B.4  Terminates

         The successful terminate shall normally have an empty data
         field.  The unsuccessful terminate may have a data field
         defined by the data types A (octal 101) for ASCII, E (octal
         105) for EBCDIC, or S (octal 123) for status.

         A data type code of 'S' would imply byte oriented error return
         status codes in the data field.  The following error return
         status codes are defined tentatively:

         Error Code Meaning                        Error Code
                                             ASCII   Octal  Hexadecimal

         Undefined error                       U       125     55
         Transaction type error                T       124     54
         Syntax error                          S       123     53
         File search failed                    F       106     46
         Data type error                       D       104     44
         Access denied                         A       101     41
         Improper transaction sequence         I       111     49
         Time-out error                        O       117     4F
         Error condition by system             E       105     45

   2C.   Semantics

   2C.1  Requests

         Requests are always sent by using host.  In absence of a device
         name or complete pathname, default options should be provided
         for all types of requests.

         _Identify_ request identifies the user as indicated by
         <pathname> from serving to using host.

         _Retrieve_ request achieves the transfer of file specified in
         <pathname> from serving to using host.



Bhushan                                                         [Page 7]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         _Store_  request achieves the transfer of file specified in
         <pathname> from using to serving host.

         _Append_ request causes data to be added to file specified in
         pathname.

         _Rename_ request causes name of file specified in <pathname> to
         be replaced by name specified in <name>.

         _Delete_ request causes file specified in <pathname> to be
         deleted.  If an extra level of protection for delete is desired
         (such as the query 'Do you wish to delete file x?'), it is to
         be a local implementation option.

         _Addname_ and _deletename_ requests cause names in <filenames>
         to be added or deleted to existing names of file specified in
         <pathname>.  These requests are useful in systems such as
         Multics which allow multiple names to be associated with a
         file.

         _Lookup_ request achieves the transfer of attributes (such as
         date last modified, access list, etc) of file specified in
         <pathname>, instead of the file itself.

         _Open_ request does not cause a data transfer, instead file
         specified in <pathname> is "opened" for retrieve (read) or
         store (write).  Subsequent requests are then treated as
         requests pertaining to the file that is opened till such a time
         that a close request is received.

         _Execute_ request achieves the execution of file specified in
         <pathname>, which must be an executable program.  Upon receipt
         of rr response, using host will transmit the necessary input
         data (parameters, arguments, etc).  Upon completion of
         execution serving host will send the results to using host and
         terminate [12].

   2C.2  Response

         Responses are always sent by serving host.  The rr response
         indicates that serving host is ready to receive the file
         indicated in the preceding request.  The rs response indicates
         that the next transaction from serving host will be the
         transfer of file indicated in the preceding request.







Bhushan                                                         [Page 8]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   2C.3  Transfers

         Transfers may be sent by either host.  Transfer transactions
         indicate the transfer of file indicated by a request.  Files
         can be transferred either as complete_file transactions or as
         part_of_file transactions followed by last_part transactions.
         The file may also have a heading transaction in the beginning.
         The syntax of a file, therefore, may be defined as:

         <file> ::= <text> | <heading> <text>
         <text> ::= <complete_file> | <parts> <last_part>
         <parts> ::= <part_of_file> | <parts> <part_of_file>

         Headings may be used to communicate the attributes of files.
         The form of headings is not formally specified but is discussed
         in Section IV as possible extension to this protocol.

   2C.4  Terminates

         The successful terminate is always sent by serving host.  It
         indicates to using host that serving host has been successful
         in serving the request and has gone to an initial state.  Using
         host will then inform user that his request is successfully
         served, and go to an initial state.

         The unsuccessful terminate may be sent by either host.  It
         indicates that sender of the terminate is unable to (or does
         not not wish to) go through with the request.  Both hosts will
         then go to their initial states.  The using host will inform
         the user that his request was aborted.  If any reasons for the
         unsuccessful terminate (either as text or as error return
         status codes) are received, these shall be communicated to the
         user.

3.    Transaction Sequence

   3A.   The transaction sequence may be defined as an instance of file
         transfer, initiated by a request and ended by a terminate [13].
         The exact sequence in which transactions occur depends on the
         type of request.  A transaction sequence may be aborted anytime
         by either host, as explained in Section 3C.

   3B.   Examples

         The identify request doesn't require a response or terminate
         and constitutes a transaction sequence by itself.





Bhushan                                                         [Page 9]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         Rename, delete, addname, deletename and open requests involve
         no data transfer but require terminates.  The user sends the
         request and the server sends a successful or an unsuccessful
         terminate depending on whether or not he is successful in
         complying with the request.

         Retrieve and Lookup requests involve data transfer from the
         server to the user.  The user sends the request, the server
         responds with a rs, and transfers the data specified by the
         request.  Upon completion of the data transfer, the server
         terminates the transaction sequence with a successful terminate
         if all goes well, or with an unsuccessful terminate is errors
         were detected.

         Store and Append requests involve data transfer from the user
         to server.  The user sends the request and the server responds
         with a rr.  The user then transfers the data.  Upon receiving
         the data, the server terminates the sequence.

         Execute request involves transfer of inputs from user to
         server, and transfer of outputs from server to user.  The user
         sends the request to which the server responds with rr.  The
         user then transfers the necessary inputs.  The server
         "executes" the program or subroutine and transfers the outputs
         to the user.  Upon completion of the output transfer, the
         server terminates the transaction sequence.

   3C.   Aborts

         Either host may abort the transaction sequence at any time by
         sending an unsuccessful terminate, or by closing the connection
         (NCP to transmit a CLS for the connection).  The CLS is a more
         drastic type of abort and shall be used when there is a
         catastrophic failure or when an abort is desired in the middle
         of a long file transfer.  The abort indicates to the receiving
         host that the other host wishes to terminate the transaction
         sequence and is now in the initial state.  When CLS is used to
         abort, the using host will reopen the connection.

4.    Data Types

   4A.   The data type code together with the extension code defines the
         manner in which the data field is to be parsed and interpreted
         [14].  Although a large number of data types are defined,
         specific implementations may handle only a limited subset of
         data types.  It is recommended that all host sites accept the





Bhushan                                                        [Page 10]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         "network ASCII" and "binary" data types.  Host computers which
         do not "recognize" particular data types may abort the
         transaction sequence and return a data type error status code.

   4B.   The following data types are tentatively defined.  The code in
         the type and extension field is represented by its ASCII
         equivalent with 8th bit as zero.












































Bhushan                                                        [Page 11]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


        Data Type                                    Code
                                     Byte Size       Type     Extension
ASCII character, bit8=0 (network)       8             A          NUL

ASCII characters, bit8=1                8             A          1

ASCII characters, bit8=even parity      8             A          E

ASCII characters, bit8=odd parity       8             A          O

ASCII characters, 8th bit info.         8             A          8

ASCII characters, 7 bits                7             A          7

ASCII characters, in 9-bit field        9             A          9
ASCII formatted files (with SOH,