home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / tagged4.txt < prev    next >
Text File  |  2020-01-01  |  10KB  |  221 lines
  1. 19-Mar-96 22:07:43-GMT,10249;000000000001
  2. Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.3/8.7.3) id RAA19030; Tue, 19 Mar 1996 17:07:04 -0500 (EST)
  3. Date: Tue, 19 Mar 96 17:07:04 EST
  4. From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
  5. To: John Santos <jasantos@ultranet.com>
  6. Subject: Re: PDP-11 Kermit
  7. In-Reply-To: Your message of Tue, 19 Mar 1996 15:28:40 -0500 (EST)
  8. Message-ID: <CMM.0.90.4.827273224.fdc@watsun.cc.columbia.edu>
  9.  
  10. >  Please send me the spec.
  11. > 
  12. Here it is -- any questions, send them to me, Terry, and Billy; hopefully
  13. we can resolve anything that needs resolving in the direction of
  14. interoperability among all RMS and/or FILES-11 systems.
  15.  
  16. ----
  17.  
  18. Kermit programs presently differentiate between text and binary files via
  19. the SET FILE TYPE command.  When the file type is TEXT, the Kermit program
  20. that is sending the file converts the file's record format and character set
  21. from its local form to a standard form, and the receiving Kermit program
  22. converts from the standard form into its own local record format and character
  23. set.  When the file type is BINARY, the file is sent as-is, byte for byte.
  24.  
  25. These two ways of handling files are sufficient in many cases, but fall short
  26. when one or both computers has a complex file system, such as the Macintosh or
  27. DEC operating systems like VAX/VMS.  The Kermit protocol includes a mechanism
  28. for transmitting a file's attributes in a generic way, but these attributes
  29. are of little use when the file is being received by a computer with a simple
  30. file system, such as UNIX or MS-DOS, that can't do anything with them.  And
  31. they are not sufficient to convey every conceivable bit of information about
  32. about every kind of file on every kind of computer.
  33.  
  34. To allow a complicated file to be transferred, a new file type is proposed:
  35.  
  36.   SET FILE TYPE LABELED
  37.  
  38. Notice the spelling of "LABELED" (only one L between the E's).  When this
  39. setting is in effect, the sending Kermit sends not only the file's data, but
  40. also system-dependent structural information about the file.  Since this
  41. information can be quite lengthy, it is sent as if it were file data, in data
  42. packets preceding the actual file data, rather than in attribute packets.  All
  43. of this information is sent in binary mode (no conversions).
  44.  
  45. The receiver of the file can elect whether to act upon the label information,
  46. or simply store it.  Kermit programs for simple file systems need no changes,
  47. and can still act as repositories for labeled files, to be sent back later to
  48. the system of origin.  On the other hand, labeled file transfers between like
  49. systems (e.g. two VAX/VMS computers) will result in the reception of a file
  50. with all the correct characteristics.
  51.  
  52. There are two possible modes of operation.  The first (and safer) mode
  53. requires human intervention on a per-file basis, but an automatic mode is also
  54. possible.
  55.  
  56. DEFINITIONS
  57.  
  58. A "bare" file is a file stored on disk that does NOT contain, as part of
  59. its contents, Kermit-constructed label information.
  60.  
  61. A "labeled" file is a file stored on disk whose contents include
  62. Kermit-constructed label information.
  63.  
  64. FORMAT OF A LABELED FILE
  65.  
  66. This description applies to a labeled file as stored on disk and to a bare
  67. file that has label information added to it by a sending Kermit.
  68.  
  69.   BANNER  The literal text string "KERMIT LABELED FILE:", just the twenty
  70.           characters within the quotes including the trailing colon, in 7-bit
  71.           ASCII.  ASCII is used even on non-ASCII systems (like IBM mainframes
  72.           with EBCDIC).
  73.  
  74.   IDLEN   A 2-byte ASCII decimal numeric length field, with leading zeros if
  75.           necessary, for example "02".
  76.  
  77.   SYSID   The system ID, one of the codes listed on pp.275-278 of the Kermit
  78.       book.  This is a string of 1 to 99 ASCII characters (but typically
  79.           1-3 characters), for example "D7" for (Open)VMS.  The length of the
  80.           SYSID field is given by the preceding field (IDLEN):
  81.  
  82.           D7 = VMS
  83.           D8 = RSX-11
  84.           D9 = IAS
  85.           DA = RSTS/E
  86.           DB = RT-11 or TSX+
  87.           DC = P/OS
  88.  
  89.   LBLEN   A 2-byte ASCII numeric length field, with leading zeros if
  90.           necessary, for example "00", "02", "09", "99".
  91.  
  92.   LABEL   A label field, 1 to 99 ASCII characters.  The length is given by
  93.           the preceding length field (LBLEN).  The LABEL field contains the
  94.           name of the file descriptor data that follows.
  95.  
  96.   VALEN   An 8-byte ASCII numeric length field, with leading zeros if 
  97.           necessary, for example "00000512".  Zero ("00000000") is a
  98.           permissible length for a value.
  99.  
  100.   VALUE   The value associated with the label, 0 to 99999999 bytes of
  101.           information about the file in system-dependent format.  The labels
  102.           and the format and layout of the associated values for each system
  103.           type should be clearly defined and documented.
  104.  
  105.      The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many
  106.      labeled values are needed (if VALEN is zero, then VALUE is omitted).
  107.  
  108.   CONTENT The file's contents, encoded in whatever form that, in combination
  109.           with the labeled values, allows for its eventual reconstruction in
  110.           its original form.
  111.  
  112. REQUIRED LABELS
  113.  
  114. The following labels (composed of ASCII uppercase letters) are reserved, and
  115. are required in every labeled file:
  116.  
  117.   VERS    The operating system version, e.g. "5.3-1"
  118.  
  119.   DATA    This is the final label.  It has a zero-length value, which is
  120.           followed immediately by the file's contents, as defined above.
  121.           See example below.
  122.  
  123. EFFECTS ON THE KERMIT PROTOCOL
  124.  
  125. When SET FILE TYPE LABELED is in effect, the sending Kermit should include
  126. the file type (") attribute, specifying a type of binary (B), if attribute
  127. packets have been negotiated.  Otherwise, there is no effect on the protocol
  128. at all.  In particular, a label-wise Kermit program can interoperate perfectly
  129. well with another Kermit program that is completely ignorant of labeling, in
  130. which case the latter program simply "archives" the file, labels and all.
  131.  
  132. This proposal does not rule out the system-independent type of file archiving,
  133. based on file attribute packets, that is described in the Kermit book.
  134. However, if the "system-dependent" attributes suggested by this proposal can
  135. be worked out in a sufficiently generic fashion, this may lead to a more
  136. effective type of transmission of complex files between unlike systems that
  137. share similar types of file characteristics (block size, record format,
  138. character set, carriage control, etc).
  139.  
  140. On the other hand, for the first pass at an implementation (for VMS), it might
  141. make more sense to simply have a single system-dependent label, like "FAB",
  142. whose value is simply the File Access Block, and perhaps another one like
  143. "ACL" for its Access Control List.  The two approaches do not rule each other
  144. out.
  145.  
  146. USER INTERFACE
  147.  
  148. When SENDING a file, the user should first determine whether it is a bare file
  149. or a labeled file.  This can be done by visual inspection (looking at the
  150. first 20 bytes), or from memory (e.g. because all labeled files have a
  151. particular filetype, or are kept together in a certain directory).  Then:
  152.  
  153.   (a) If it is a bare file, use SET FILE TYPE LABELED if you want to send 
  154.       label information too.
  155.  
  156.   (b) If it is a labeled file, use SET FILE TYPE BINARY.
  157.  
  158. When receiving a file, use SET FILE TYPE LABELED if you want labels in the
  159. incoming file to be interpreted and applied, and:
  160.  
  161.  (a) The other Kermit is sending a bare file from a like system using SET 
  162.      FILE TYPE LABELED, or:
  163.  
  164.  (b) The other Kermit is sending a labeled file, of the receiving system's
  165.      system type, from any kind of system, without SET FILE TYPE LABELED.
  166.  
  167. The receiving Kermit program that has been given a SET FILE TYPE LABELED
  168. command must inspect the incoming data.  The first 30-36 bytes of the first
  169. packet contain the BANNER, IDLEN, SYSID, and the first LBLEN, and LABEL (which
  170. should be "04VERS").  If these five items are in correct format, and the SYSID
  171. matches the program's own, then the program will accept the file in labeled
  172. mode.  Otherwise, it will treat it as a binary file and store all the data,
  173. including BANNER, SYSID, LABELs, VALUEs, and all length fields.
  174.  
  175. If a receiving Kermit program has accepted the file in labeled mode, but then
  176. encounters an unknown label or other inconsistency in the labeled file format,
  177. it must interrupt the file transfer (by putting an X in the data field of the
  178. first available ACK) and discard the file.  This is because it cannot be
  179. expected to back up and undo whatever label interpretation it has already done.
  180.  
  181. It is also conceivable that "similar" systems -- such as the DEC operating
  182. systems VMS and RSX-11 -- might be able to honor each other's labels.  This
  183. eventuality should be allowed for, possibly with SET commands.
  184.  
  185. At the discretion of the programmer, a command such as SET FILE
  186. LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed.  If so, the default
  187. must be MANUAL, that is, processing of labeled files occurs only if the user
  188. asks for it explicitly.  For an arriving file, AUTOMATIC mode would detect the
  189. BANNER, SYSID, and first LABEL and go into action as if the user had SET FILE
  190. TYPE LABELED.  When sending a file, the program would avoid adding surrounding
  191. label information if the user had already SET FILE TYPE LABELED.  This sort of
  192. thing is obviously dangerous, and users should be cautioned about it.
  193.  
  194. EXAMPLE
  195.  
  196. A hypothetical example for VMS (ignore the indentation and line breaks);
  197. the length fields are marked with L's:
  198.  
  199.                       LL  LL    LLLLLLLL     LL   LLLLLLLL
  200.   KERMIT LABELED FILE:02D704VERS000000055.3-103FAB00000512<512 bytes here>
  201.   03ACL00000723<723 bytes here>02DATA00000000<file's contents here>
  202.   LL   LLLLLLLL                LL    LLLLLLLL
  203.  
  204. Note: FAB and ACL are not necessarily real labels.
  205.  
  206. POSTPROCESSING
  207.  
  208. Separate programs should be provided to translate a labeled file into a real
  209. file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file
  210. was deposited by means other than Kermit.  Such a program might have two
  211. options (or come in two forms): interpret the labels, and simply strip the
  212. labels.
  213.  
  214. (End)
  215.  
  216. You can find the VMS implementation in the file ckvfio.c in the Kermit
  217. archives.
  218.  
  219. - Frank
  220.  
  221.