rfc114.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 956 行 · 第 1/3 页

        STX, ETX, etc.)                 8             A          F
DEC-packed ASCII (5 7-bit char.,
        36th bit 1 or 0)                36            A          D
EBCDIC characters                       8             E         NUL
SIXBIT characters                       6             S         NUL
Binary data                             1             B         NUL
Binary bytes (size is binary ext.)      1-255         B        (any)
Decimal numbers, net ASCII              8             D          A
Decimal numbers, EBCDIC                 8             D          E
Decimal numbers, sixbit                 6             D          S
Decimal numbers, BCD (binary coded)     4             D          B
Octal numbers, net. ASCII               8             O          A
Octal numbers, EBCDIC                   8             O          E
Octal numbers, SIXBIT                   6             O          S
Hexadecimal numbers, net. ASCII         8             H          A
Hexadecimal numbers, EBCDIC             8             H          E
Hexadecimal numbers, SIXBIT             6             H          S
Unsigned integers, binary (ext.
        field is byte size)             1-225         U        (any)
Sign magnitude integers (field is
        binary size)                    1-255         I        (any)
2's complement integers (ext.
        field is byte size)             1-255         2        (any)
1's complement integers (ext.
        field is byte size)             1-255         1        (any)
Floating point (IBM360)                 32            F          I
Floating point (PDP-10)                 36            F          D
Status codes                            8             S         NUL







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


   4C.   The data type information is intended to be interpretive.  If a
         host accepts a data type, it can interpret it to a form suited
         to its internal representation of characters or numbers [15].
         Specifically when no conversion is to be performed, the data
         type used will be binary.  The implicit or explicit byte size
         is useful as it facilitates storing of data.  For example, if a
         PDP-10 receives data types A, A1, AE, or A7, it can store the
         ASCII characters five to a word (DEC-packed ASCII).  If the
         datatype is A8 or A9, it would store the characters four to a
         word.  Sixbit characters would be stored six to a word.  If
         conversion routines are available on a system, the use of
         system program could convert the data from one form to another
         (such as EBCDIC to ASCII, IBM floating point to DEC floating
         point, Decimal ASCII to integers, etc.).

5. Initial Connection, CLS, and Identifying Users

   5A.   There will be a prearranged socket number [16] for the
         cooperating process on the serving host.  The connection
         establishment will be in accordance with the initial connection
         protocol of RFC 66 as modified by RFC 80.  The NCP dialog would
         be:

              user to server:    RTS<us><3><p>

         if accepted, server to user:    STR<3><us><CLS><3><us>
              server to user on link p:  <ss>
              server to user:    STR<ss+1><us>RTS<ss><us+1><q>
              user to server:    STR<us><ss+1>RTS<us+1><ss><r>

         This sets up a full-duplex connection between user and server
         processes, with server receiving through local socket ss from
         remote socket us+1 via link q, and sending to remote socket us
         through local socket ss+1 via link r.

   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 the CLS.

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

   5C.   The first transaction from the user to server will be the
         identify transaction.  The users will be identified by the
         pathname in data field of the transaction which should be a



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


         form acceptable to the server.  The server is at liberty to
         truncate pathnames for its own use.  Since the identify
         transaction does not require a response or terminate, the user
         can proceed directly with other requests.

IV.  Extensions to Protocol

   The protocol specified above has been designed to be extendable.  The
   obvious extensions would be in the area of transaction types (new
   types of requests), error return status words, and data types.  Some
   of the non-obvious extensions, that I can visualize are provisions of
   access control mechanisms, developing a uniform way of specifying
   file attributes in headings of files, increasing the scope of the
   execute command to include subroutine mediation, and the provision of
   transaction sequence identification numbers to facilitate handling of
   multiple requests over the same connection pair.

   Users of protected file systems should be able to have a reasonable
   degree of confidence in the ability of the serving process to
   identify remote users correctly.  In the absence of such confidence,
   some users would not be willing to give access to the serving process
   (especially write access).  Inclusion of access control mechanisms
   such as passwords, is likely to enhance the indirect use of network
   by users who are concerned about privacy and security.  A simple
   extension to the protocol would be to have the serving host sent a
   transaction type "password?" after it receives user name.  Upon
   receipt of "password?" the using host will transmit the password,
   which when successfully acknowledged, would indicate to the user that
   requests may proceed.

   There are a number of file attributes which properly belong in the
   heading of a file rather than the file itself or the data type in
   descriptors of transactions.  Such attributes include access control
   lists, date file was last modified, information about the nature of
   file, and description of its contents in a data description or data
   reconfiguration language.  Some uniformity in the way file attributes
   are specified would be useful.  Until then, the interpretation of the
   heading would be up to the user or the using process.  For example,
   the heading of files which are input to a data reconfiguration (form)
   machine may be the desired transformations expressed in the
   reconfiguration language.

   The "execute" command which achieves the execution of programs
   resident in remote hosts is a vital part of indirect use of remote
   hosts.  The present scope of the execute command, as outlined in the
   specifications, is somewhat limited.  It assumes that the user or





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


   using process is aware of the manner in which the arguments and
   results should be exchanged.  One could broaden the scope of the
   execute command by introducing a program mediation protocol [17].

   The present specification of the protocol does not allow the
   simultaneous transfer and processing of multiple requests over the
   same pair of connections.  If such a capability is desired, there is
   an easy way to implement it which only involves a minor change.  A
   transaction sequence identification number (TSid) could replace a NUL
   field in the descriptor of transactions.  The TSid would facilitate
   the coordination of transactions, related to a particular transaction
   sequence.  The 256 code combinations permitted by the TSid would be
   used in a round-robin manner (I can't see more than 256 outstanding
   requests between two user-processes in any practical implementation).
   An alternate way of simultaneous processing of requests is to open
   new pairs of connection.  I am not sure as to how useful simultaneous
   processing of requests is, and which of the two is a more reasonable
   approach.

V. Conclusions

   I tried to present a user-level protocol that will permit users and
   using programs to make indirect use of remote host computers.  The
   protocol facilitates not only file system operations but also program
   execution in remote hosts.  This is achieved by defining requests
   which are handled by cooperating processes.  The transaction sequence
   orientation provides greater assurance and would facilitate error
   control.  The notion of data types is introduced to facilitate the
   interpretation, reconfiguration and storage of simple and limited
   forms of data at individual host sites.  The protocol is readily
   extendible.

Endnotes

   [1] The interim version of the protocol, limited to transfer of ASCII
   files, was developed by Chander Ramchandani and Howard Brodie of
   Project MAC.  The ideas of transactions, descriptors, error recovery,
   aborts, file headings and attributes, execution of programs, and use
   of data types, pathnames, and default mechanisms are new here.
   Howard Brodie and Neal Ryan have coded the interim protocol in the
   PDP-10 and the 645, respectively.

   [2] The network system survey was conducted last fall by Howard
   Brodie of Project MAC, primarily by telephone.

   [3] PDP-10 Reference Handbook, page 306.





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


   [4] We considered using two full-duplex links, one for control
   information, the other for data.  The use of a separate control link
   between the cooperating processes would simplify aborts, error
   recoveries and synchronization.  The synchronization function may
   alternatively be performed by closing the connection (in the middle
   of a transaction sequence) and reopening it with an abort message.
   (The use of INR and INS transmitted via the NCP control link has
   problems as mentioned by Kalin in RFC 103.)  We prefer the latter
   approach.

   [5] Identifying users through use of socket numbers is not practical,
   as unique user identification numbers have not been implemented, and
   file systems identify users by name, not number.

   [6] This subject is considered in detail by Bob Metcalfe in a
   forthcoming paper.

   [7] Filler bits may be necessary as particular implementations of
   NCP's may not allow the free communication of bits.  Instead the
   NCP's may only accept bytes, as suggested in RFC 102.  The filler
   count is needed to determine the boundary between transactions.

   [8] 72-bits in descriptor field are convenient as 72 is the least
   common multiple of 6, 8, 9, 18, 24 and 30, the commonly encountered
   byte sizes on the ARPA network host computers.

   [9] The execute request is intended to facilitate the indirect
   execution of programs and subroutines.  However, this request in its
   present form may have only limited use.  A subroutine or program
   mediation protocol would be required for broader use of the execute
   feature.  Metcalfe considers this problem in a forthcoming paper.

   [10] The pathname idea used in Multics is similar to that of labels
   in RFC 76 by Bouknight, Madden and Grossman.

   [11] We, however, urge the use of standard network ASCII.

   [12] The exact manner in which the input and output are transmitted
   would depend on specific mediation conventions.  Names of input and
   output files may be transmitted instead of data itself.

   [13] The transactions (including terminate) are not "echoed", as
   echoing does not solve any "hung" conditions.  Instead time-out
   mechanisms are recommended for avoiding hang-ups.

   [14] The data type mechanism suggested here does not replace data
   reconfiguration service suggested by Harslem and Heafner in RFC 83
   and NIC5772.  In fact, it complements the reconfiguration.  For



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


   example, data reconfiguration language can be expressed in EBCDIC,
   Network ASCII or any other code that form machine may "recognize".
   Subsequent data may be transmitted binary, and the form machine would
   reconfigure it to the required form.  I have included in data types,
   a large number suggested by Harslem and Heafner, as I do not wish to
   preclude interpretation, reconfiguration and storage of simple forms
   of data at individual host sites.

   [15] The internal character representation in the hosts may be
   different even in ASCII.  For example PDP-10 stores 7-bit characters,
   five per word with 36th bit as don't care, while Multics stores them
   four per word, right-justified in 9-bit fields.

   [16] It seems that socket 1 has been assigned to logger and socket 5
   to NETRJS.  Socket 3 seems a reasonable choice for the file transfer
   process.

   [17] The term program mediation was suggested by Bob Metcalfe who is
   intending to write a paper on this subject.


         [ This RFC was put into machine readable form for entry ]
             [ into the online RFC archives by Ryan Kato 6/01]




























Bhushan                                                        [Page 17]