home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / tagged2.pepmnt < prev    next >
Text File  |  2020-01-01  |  6KB  |  139 lines
  1. 17-Aug-90  0:49:33-GMT,6377;000000000001
  2. Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.HARVARD.EDU>
  3. Received: from cuvmb.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
  4.     id AA18917; Thu, 16 Aug 90 20:49:31 EDT
  5. Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 3342; Thu, 16 Aug 90 20:48:42 EDT
  6. Received: from CFAAMP.HARVARD.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.07) with
  7.  BSMTP id 4352; Thu, 16 Aug 90 20:48:40 EDT
  8. Received: from CFAAMP.HARVARD.EDU (PEPMNT) by CFAAMP.HARVARD.EDU (Mailer R2.07)
  9.  with BSMTP id 4999; Thu, 16 Aug 90 20:44:12 EDT
  10. Date: Thu, 1990 Aug 16   18:58 EDT
  11. From: "John F. Chandler"   <PEPMNT%CFAAMP.HARVARD.EDU@cuvmb.cc.columbia.edu>
  12. To: Christine M Gianone   <cmg@watsun.cc.columbia.edu>,
  13.         Joe Doupnik   <JRD@USU.BITNET>, John Chandler   <PEPMNT@CFAAMP.BITNET>,
  14.         terry   <TERRY@SPCVXA.BITNET>,
  15.         Paul Placeway   <paul@cis.ohio-state.edu>,
  16.         Frank da Cruz   <fdc@watsun.cc.columbia.edu>
  17. Subject: Re: Labeled File Proposal
  18. In-Reply-To: cmg@watsun.cc.columbia.edu message
  19.   <CMM.0.88.650827454.cmg@watsun.cc.columbia.edu> of Thu, 16 Aug 90 13:24:14 EDT
  20. Message-Id: <PEPMNT.900816.185841.C0@CFAAMP.HARVARD.EDU>
  21.  
  22. > have written draft 3, which embodies just about all of
  23. > those comments.  Is it OK with everybody?
  24.  
  25. I can see a lot of careful rewriting got done.  It looks much better, but
  26. there are a couple of points that need clarifying.
  27.  
  28. >   SYSID   The system ID, one of the codes listed on pp.275-278 of the Kermit
  29. >           book.  This is 1 to 99 characters long (but typically 1-3
  30. >           characters), for example "D7" for VAX/VMS.
  31.  
  32. How about "This is a string of 1 to 99 ASCII characters (but ..."?  You
  33. might as well mention ASCII in each definition for completeness.
  34.  
  35. >                The following labels
  36. >           (composed of ASCII uppercase letters) are reserved:
  37. >
  38. >              VERS  - The operating system version, e.g. "5.3-1"
  39.  
  40. I think this label should be not only reserved, but also required and,
  41. moreover, required to be first, even if the value has a zero length.
  42. This could (and should) be added to the criteria of the (optional)
  43. automatic label detector.
  44.  
  45. Yes, I think zero-length values should be explicitly permitted right
  46. off the top.  That possibility would otherwise be a lurking bug in
  47. some implementations.
  48.  
  49. >              DATA  - This is the final label.  What follows is the file's
  50. >                      contents, byte for byte.
  51.  
  52. Maybe add "i.e., this label has no value, unlike all other labels"?
  53. Alternatively, it might be easier to explain if we don't make such an
  54. exception, and say instead
  55.  
  56.         DATA  - This is the final label.  It's value (see below) must
  57.                 have a length of zero.  What follows that is ...
  58.  
  59. >   VALUE   The value associated with the label, up to 999999999 bytes of
  60.                                                        99999999
  61.  
  62. >      The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many
  63. >      labeled values are needed.
  64.  
  65. If the DATA label has no VALEN, that exception should be repeated here
  66. for clarity.
  67.  
  68. >   DATA    The file's data, as-is, byte-for-byte, as stored on the disk, not
  69. >           preceded by a length field.
  70.  
  71. The lack of a length field would be doubly clear if the above-mentioned
  72. amplifications were made concerning the "DATA" label.
  73.  
  74. >                           No character set translation, record
  75. >           format conversion, or any other modifications.
  76.  
  77. Well, here is a problem.  Complex structured files generally cannot be
  78. represented as a simple byte stream.  In particular, storage on disk
  79. implies clumping the data into blocks or records, and perhaps into
  80. tracks and even into cylinders.  Such clumping may (depending on the
  81. operating system) be an integral part of the file.  Whenever the block
  82. lengths are not strictly bound to be all the same, the Kermit stream
  83. must include each block's length -- very much as in Kermit-370's
  84. V-BINARY type.  I think you need to say "or any other modifications
  85. other than those specified or implied in the label information."
  86.  
  87. > at all.  In particular, a label-wise Kermit program can interoperate perfectly
  88. > well with another Kermit program that is completely ignorant of labeling, in
  89. > which case the latter program simply "archives" the file, labels and all.
  90.  
  91. Add "(provided that the user remembers to place it in binary mode)."
  92.  
  93. > USER INTERFACE
  94.  
  95. It would be good to begin with a preamble that mentions up front that
  96. automatic label detection is a possibility.  For example:
  97.  
  98. "There are two possible modes of operation.  The first (and safer)
  99.  mode requires human intervention, but there may also be an automatic
  100.  mode (see below)."
  101.  
  102. > When SENDING a file, the user should first determine whether it is a bare file
  103.  
  104. Begin "In the normal mode, when SENDING a file..."
  105.  
  106. > The receiving Kermit program that has been given a SET FILE TYPE LABELED
  107. > command must inspect the incoming data.  The first 24-30 bytes of the first
  108.                                                      30-36
  109.  
  110. > packet contain the BANNER, the IDLEN, and the SYSID.
  111.                              IDLEN, SYSID, and the first LBLEN and LABEL.
  112.  
  113. >                                If these three items are
  114.                                            five
  115.  
  116. If my suggestion of requiring the VERS label to be first is adopted,
  117. it's a trivial addition to check for the next six bytes after SYSID:
  118. they will always be "04VERS".  For that matter, you could also inspect
  119. the first VALEN to make sure it's all ASCII decimal digits, but it's
  120. really a question of how failsafe you want the checking to be.
  121. Personally, I want it to be as safe as possible within reason because
  122. automatic label detection is such a nice feature.  Anyway, adding that
  123. little extra check would mean
  124.                                                      38-44
  125.                              IDLEN, SYSID, and the first LBLEN, LABEL and
  126. VALEN.
  127.                                            six
  128.  
  129. > LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed.  Is so, the default
  130.                                                              If
  131.  
  132. > asks for it explicitly.  For an arriving file, AUTOMATIC mode would detect the
  133. > BANNER and SYSID and go into action as if the user had SET FILE TYPE LABELED.
  134.         , SYSID, and first LABEL and go...
  135.  
  136. Gads, how did I manage to write so much?
  137.                                   John
  138.  
  139.