home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / tagged.txt < prev    next >
Text File  |  2020-01-01  |  9KB  |  165 lines
  1. > To: cmg@watsun.cc.columbia.edu
  2. > From: Paul W Placeway <pplacewa@BBN.COM>
  3. > Subject: Tagged Files...
  4. > Date: Tue, 7 Aug 90 13:42:38 EDT
  5. > 
  6. > Ummmm....  It's a good idea, but not for the Macintosh.
  7. > 
  8. > I'm fairly shure that it would be a Bad Thing to have a non-standard
  9. > (in the Mac community) version of MacBinary.  The existing MacBinary
  10. > standard does exactly what is required (for the Mac), and
  11. > implimentations are compatible between MacKermit, NCSA Telnet,
  12. > MicroPhone, VersaTerm, ... (which is a BIG win).
  13. > 
  14. > So I guess what I would suggest is to use MacBinary to store Mac files
  15. > on forign file systems, and do something more reasonable for VMS etc.
  16. > It isn't a nice general orthogonal approach, but it also won't screw
  17. > up existing usage, and the Mac version of Kermit is the only one that
  18. > actually has to deal with it.
  19. > 
  20. Right, the Mac already has MacBinary, and should continue to use it for
  21. interoperability with the commercial Mac communication programs that also
  22. do MacBinary Kermi transfers.  Changing Mac Kermit to do it "the new way"
  23. wasn't really a serious suggestion.  But the Mac is a good example of the
  24. kind of weird file system that needs this kind of treatment.  But from the
  25. point of view of the protocol, it will be an odd case, like CMS Kermit and
  26. SET FILE TYPE V-BINARY.  This is not a bad thing.  The alternative (adding
  27. MacBinary and V-Binary to the protocol) is not a good idea, though,
  28. because then every Kermit in the world would need to have SET FILE TYPE
  29. MACBINARY and V-BINARY added to it, just so it could send a special
  30. file-type attribute.  Better to leave things as they stand, and let the
  31. user of Mac Kermit or CMS Kermit indicate the special treatment on the
  32. computer that knows about it.
  33.  
  34. ------------------------------
  35.  
  36. > Date: Tue, 7 Aug 90 11:55 MDT
  37. > From: Joe Doupnik <JRD@cc.usu.edu>
  38. > Subject: Tagged files proposal
  39. > 
  40. >     Nice idea so far, but it lacks most internals. For example, TAGs
  41. > implies tags, naturally, and that means a field devoted to the kind-of
  42. > information which follows. I suppose that 4 character numbers are ok for
  43. > lengths, but the 6 character item seems excessive.
  44. >
  45. Yes, but why be stingy.  Given the way that OS/2 and MS-Windows eat up
  46. memory, it's not inconceivable that files of the future could have
  47. megabyte-long "resource forks" or whatever...  Come to think of it, maybe
  48. 6 bytes isn't long enough!
  49.  
  50. >     Personally I'd do the organization without a leading count of the
  51. > number of tags. An overall count is messy in the program and leads to
  52. > trouble if the actual count differs. Rather, I would use TAGging as it was
  53. > intended: each field is independent of the others, identifies itself as a
  54. > tag-thing and then comes length of tag-dependent data which follows
  55. > immediately thereafter.  One tag is reserved for "this is the end of
  56. > tagging stuff, no tagged data for me either." This places limits on the
  57. > number of different tags, but a two byte field ought to cover even the
  58. > most obtuse file system.
  59. >
  60. Having distinguished tags would slow down the innermost loop of Kermit
  61. file transfer -- the decoding of packets.  It also introduces transparency
  62. problems.  If the tag is "FOO", then what happens when FOO occurs in the
  63. data?  Since the file is being transferred in binary mode, the count will
  64. be accurate.
  65.  
  66. >     There really should be an operating system release level (and
  67. > whatever other factors are needed) to pinpoint the file system
  68. > particulars. This is machine dependent, of course.
  69. >
  70. Does everybody think this is important?  If so, we have to come up with
  71. some kind of "standard" for how to write the OS version.
  72.  
  73. >     There should be a way of rejecting a tagged file if one or more of
  74. > the tags turns out to be incompatible with the receiver. It wouldn't know
  75. > about the problem until that tag is processed. The returned error message,
  76. > if any, should be generic enough to not require large amounts of program
  77. > space to chat about every possible tag.
  78. >
  79. The regular old interruption mechanism (X in ACK to D packet) should do
  80. the trick.  Unfortunately, this does not return an error message.  An E
  81. packet could also be used: it certainly gets the job done!  And it can
  82. contain an error message like "Invalid format for tagged file".
  83.  
  84. > I think it is not reasonable to
  85. > expect the receiver to backup and write the file as literal binary, tags
  86. > and all, if incompatibilities arise in the tag information; that requires
  87. > holding far too much information in original form.
  88. >
  89. Agreed.
  90.  
  91. >     Directory information. This is an interesting thing. The reason I
  92. > say so is that Novell is now supporting multiple name spaces for files, a
  93. > file name structure for each of several file system styles for each real
  94. > file. DOS, MAC, and VMS, and probably Unix are the immediate kinds, with
  95. > the first two having been implemented already (I run such a system).
  96. > Consequently, one tagged item might well be the filename in native form,
  97. > with embedded spaces or high-bits or whatever. Btw, this also raises a
  98. > point that the tried and true 8.3 filename rule is now out of fashion, and
  99. > will be so shortly even on OS/2 based PCs. A Capabilities bit permitting
  100. > longer filenames would be nice to have in I/S packets.
  101. >     Clearly, the meaning of the tags is strictly operating system
  102. > dependent. Otherwise we would have to catalogue all the likely o/s' in the
  103. > civilized world and that gets out of hand.
  104. > 
  105. So for each OS we need to define the format of the TAG field carefully.
  106. Let's experiment with VMS and see how it works, and then refine the idea
  107. based on our experience.
  108.  
  109. ------------------------------
  110.  
  111. > Date: Tue, 7 Aug 90 13:38 MDT
  112. > From: Joe Doupnik <JRD@cc.usu.edu>
  113. > Subject: Tagged files proposal, cont'd
  114. > 
  115. > The group:
  116. >     A couple more points I should have mentioned last time.
  117. >     The usefulness of tagged files is really limited to machines
  118. > running the same version of the same o/s. Sending from a New to an Old
  119. > system likely gives troubles from features added to New, and in the other
  120. > direction from features obsoleted away in New.
  121.  
  122. >     Exchanging files between unlike machines is not so good either,
  123. > because once stored as Binary on the destination it can't come back as
  124. > Tagged (whose tags??). The fact that a file has its tags held at the front
  125. > of the file is not a property of the file (the destination can't remember)
  126. > and no one will suggest reading the front of Binary files to discover
  127. > embedded tags.
  128. >
  129. This should not be a problem.  Example: VMS Kermit sends a tagged file to
  130. DOS.  MS-DOS Kermit treats it as a binary file, and stores all the bytes
  131. without any knowledge that it contains tags, etc.  Later, MS-DOS Kermit
  132. sends the file back to VMS Kermit.  The user has to say SET FILE TYPE
  133. TAGGED to VMS Kermit to make it look in the data for the tags.  If the
  134. user doesn't give this command, then it's stored -- tags and all -- as a
  135. binary file.  But in that case, a postprocesssing program can convert it
  136. back.
  137.  
  138. Actually, there is one little problem...  MS-DOS Kermit sends the file as
  139. a binary file, so it puts a "B" in its file-type attribute, whereas VMS
  140. Kermit has been told to SET FILE TYPE TAGGED.  So which one does it do?
  141. Up till now, we have said that the contents of the attribute packet
  142. override the current settings on a per-file basis, but in this case we
  143. want the opposite to happen.  So we must choose between (a) making the
  144. current setting take precedence only if it is TAGGED, or (b) adding SET
  145. FILE TYPE TAGGED to every Kermit program so that it can put T in its
  146. outbound attribute packets, rather than B.  (a) probably makes more sense.
  147.  
  148. >     Maybe Terry has this figured out, but... What about indexed files?
  149. > Some systems treat them as sparce matricies: don't allocate space for
  150. > every possible element, but keep a record of which exist and where they
  151. > are. I would think that "raw disk i/o" (poor man's attempts of making a
  152. > flat file of this stuff) might do the wrong things.
  153. >     So, we come around to the archiving aspects. I would think that
  154. > the code in a Kermit to convert local files to flat archive files is
  155. > comparable in size (say half, for using intelligence and skill!) to the
  156. > system's own backup programs. I think of doing this stuff across a wire to
  157. > another host as akin to putting the file(s) on punched paper tape (no
  158. > backing up and redoing a tape block, regardless of finesse).
  159. >
  160. These are questions for Terry.  The VMS version would do essentially what
  161. the VMSHEX and VMSDEH programs do now, except skipping the hexification.
  162. If VMSHEX/DEH work on ISAM files, then so will this method.
  163.  
  164. - Frank & Chris
  165.