home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / archives / protocol.zip / tagged2.txt < prev    next >
Text File  |  1990-08-16  |  9KB  |  180 lines

  1. Kermit programs presently differentiate between text and binary files via
  2. the SET FILE TYPE command.  When the file type is TEXT, the Kermit program
  3. that is sending the file converts the file's record format and character set
  4. from its local form to a standard form, and the receiving Kermit program
  5. converts from the standard form into its own local record format and character
  6. set.  When the file type is BINARY, the file is sent as-is, byte for byte.
  7.  
  8. These two ways of handling files are sufficient in many cases, but fall short
  9. when one or both computers has a complex file system, such as the Macintosh or
  10. DEC operating systems like VAX/VMS.  The Kermit protocol includes a mechanism
  11. for transmitting a file's attributes in a generic way, but these attributes
  12. are of little use when the file is being received by a computer with a simple
  13. file system, such as UNIX or MS-DOS, that can't do anything with them.  And
  14. they are not sufficient to convey every conceivable bit of information about
  15. about every kind of file on every kind of computer.
  16.  
  17. To allow a complicated file to be transferred, a new file type is proposed:
  18.  
  19.   SET FILE TYPE LABELED
  20.  
  21. When this setting is in effect, the sending Kermit sends not only the file's
  22. data, but also system-dependent structural information about the file.  Since
  23. this information can be quite lengthy, it is sent as if it were file data, in
  24. data packets preceding the actual file data, rather than in attribute packets.
  25. All of this information is sent in binary mode (no conversions).
  26.  
  27. The receiver of the file can elect whether to act upon the label information,
  28. or simply store it.  Kermit programs for simple file systems need no changes,
  29. and can still act as repositories for labeled files, to be sent back later to
  30. the system of origin.  On the other hand, labeled file transfers between like
  31. systems (e.g. two VAX/VMS computers) will result in the reception of a file
  32. with all the correct characteristics.
  33.  
  34. There are two possible modes of operation.  The first (and safer) mode
  35. requires human intervention on a per-file basis, but an automatic mode is also
  36. possible.
  37.  
  38. DEFINITIONS
  39.  
  40. A "bare" file is a file stored on disk that does NOT contain, as part of
  41. its contents, Kermit-constructed label information.
  42.  
  43. A "labeled" file is a file stored on disk whose contents include
  44. Kermit-constructed label information.
  45.  
  46. FORMAT OF A LABELED FILE
  47.  
  48. This applies to a labeled file as stored on disk and to a bare file that
  49. has label information added to it by a sending Kermit.
  50.  
  51.   BANNER  The literal text string "KERMIT LABELED FILE:", just the twenty
  52.           characters within the quotes including the trailing colon, in 7-bit
  53.           ASCII.  ASCII is used even on non-ASCII systems (like IBM mainframes
  54.           with EBCDIC).
  55.  
  56.   IDLEN   A 2-byte ASCII decimal numeric length field, with leading zeros if
  57.           necessary, for example "02".
  58.  
  59.   SYSID   The system ID, one of the codes listed on pp.275-278 of the Kermit
  60.       book.  This is a string of 1 to 99 ASCII characters (but typically
  61.           1-3 characters), for example "D7" for VAX/VMS.  The length of the
  62.           SYSID field is given by the preceding field (IDLEN).
  63.  
  64.   LBLEN   A 2-byte ASCII numeric length field, with leading zeros if
  65.           necessary, for example "00", "02", "09", "99".
  66.  
  67.   LABEL   A label field, 1 to 99 ASCII characters.  The length is given by
  68.           the preceding length field (LBLEN).  The LABEL field contains the
  69.           name of the file descriptor data that follows.
  70.  
  71.   VALEN   An 8-byte ASCII numeric length field, with leading zeros if 
  72.           necessary, for example "00000512".  Zero ("00000000") is a
  73.           permissible length for a value.
  74.  
  75.   VALUE   The value associated with the label, 0 to 99999999 bytes of
  76.           information about the file in system-dependent format.  The labels
  77.           and the format and layout of the associated values for each system
  78.           type should be clearly defined and documented.
  79.  
  80.      The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many
  81.      labeled values are needed (if VALEN is zero, then VALUE is omitted).
  82.  
  83.   CONTENT The file's contents, encoded in whatever form that, in combination
  84.           with the labeled values, allows for its eventual reconstruction in
  85.           its original form.
  86.  
  87. REQUIRED LABELS
  88.  
  89. The following labels (composed of ASCII uppercase letters) are reserved, and
  90. are required in every labeled file:
  91.  
  92.   VERS    The operating system version, e.g. "5.3-1"
  93.  
  94.   DATA    This is the final label.  It has a zero-length value, which is
  95.           followed immediately by the file's contents, as defined above.
  96.  
  97. EFFECTS ON THE KERMIT PROTOCOL
  98.  
  99. When SET FILE TYPE LABELED is in effect, the sending Kermit should include
  100. the file type (") attribute, specifying a type of binary (B), if attribute
  101. packets have been negotiated.  Otherwise, there is no effect on the protocol
  102. at all.  In particular, a label-wise Kermit program can interoperate perfectly
  103. well with another Kermit program that is completely ignorant of labeling, in
  104. which case the latter program simply "archives" the file, labels and all.
  105.  
  106. This proposal does not rule out the system-independent type of file archiving,
  107. based on file attribute packets, that is described in the Kermit book.
  108. However, if the "system-dependent" attributes suggested by this proposal can
  109. be worked out in a sufficiently generic fashion, this may lead to a more
  110. effective type of transmission of complex files between unlike systems that
  111. share similar types of file characteristics (block size, record format,
  112. character set, carriage control, etc).
  113.  
  114. On the other hand, for the first pass at an implementation (for VMS), it might
  115. make more sense to simply have a single system-dependent label, like "FAB",
  116. whose value is simply the File Access Block, and perhaps another one like
  117. "ACL" for its Access Control List.  The two approaches do not rule each other
  118. out.
  119.  
  120. USER INTERFACE
  121.  
  122. When SENDING a file, the user should first determine whether it is a bare file
  123. or a labeled file.  This can be done by visual inspection (looking at the
  124. first 20 bytes), or from memory (e.g. because all labeled files have a
  125. particular filetype, or are kept together in a certain directory).  Then:
  126.  
  127.   (a) If it is a bare file, use SET FILE TYPE LABELED if you want to send 
  128.       label information too.
  129.  
  130.   (b) If it is a labeled file, use SET FILE TYPE BINARY.
  131.  
  132. When receiving a file, use SET FILE TYPE LABELED if you want labels in the
  133. incoming file to be interpreted and applied, and:
  134.  
  135.  (a) The other Kermit is sending a bare file from a like system using SET 
  136.      FILE TYPE LABELED, or:
  137.  
  138.  (b) The other Kermit is sending a labeled file, of the receiving system's
  139.      system type, from any kind of system, without SET FILE TYPE LABELED.
  140.  
  141. The receiving Kermit program that has been given a SET FILE TYPE LABELED
  142. command must inspect the incoming data.  The first 24-30 bytes of the first
  143. packet contain the BANNER, the IDLEN, and the SYSID.  If these three items are
  144. in correct format, and the SYSID matches the program's own, then the program
  145. will accept the file in labeled mode.  Otherwise, it will treat it as a binary
  146. file and store all the data, including BANNER, SYSID, LABELs, VALUEs, and all
  147. length fields.
  148.  
  149. If a receiving Kermit program has accepted the file in labeled mode, but then
  150. encounters an unknown label or other inconsistency in the labeled file format,
  151. it must interrupt the file transfer (by putting an X in the data field of the
  152. first available ACK) and discard the file.  This is because it cannot be
  153. expected to back up and undo whatever label interpretation it has already done.
  154.  
  155. It is also conceivable that "similar" systems -- such as the DEC operating
  156. systems VMS and RSX-11 -- might be able to honor each other's labels.  This
  157. eventuality should be allowed for, possibly with SET commands.
  158.  
  159. At the discretion of the programmer, a command such as SET FILE
  160. LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed.  Is so, the default
  161. must be MANUAL, that is, processing of labeled files occurs only if the user
  162. asks for it explicitly.  For an arriving file, AUTOMATIC mode would detect the
  163. BANNER and SYSID and go into action as if the user had SET FILE TYPE LABELED.
  164. When sending a file, the program would avoid adding surrounding label
  165. information if the user had already SET FILE TYPE LABELED.  This sort of thing
  166. is obviously dangerous, and users should be cautioned about it.
  167.  
  168. POSTPROCESSING
  169.  
  170. Separate programs should be provided to translate a labeled file into a real
  171. file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file
  172. was deposited by means other than Kermit.  Such a program might have two
  173. options (or come in two forms): interpret the labels, and simply strip the
  174. labels.
  175.  
  176. ACKS
  177.  
  178. Thanks to Terry Kennedy and Frank da Cruz for suggesting this idea, and to Joe
  179. Doupnik, John Chandler, and Paul Placeway for many valuable suggestions.
  180.