17-Aug-90 0:49:33-GMT,6377;000000000001 Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.HARVARD.EDU> Received: from cuvmb.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA18917; Thu, 16 Aug 90 20:49:31 EDT 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 Received: from CFAAMP.HARVARD.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.07) with BSMTP id 4352; Thu, 16 Aug 90 20:48:40 EDT Received: from CFAAMP.HARVARD.EDU (PEPMNT) by CFAAMP.HARVARD.EDU (Mailer R2.07) with BSMTP id 4999; Thu, 16 Aug 90 20:44:12 EDT Date: Thu, 1990 Aug 16 18:58 EDT From: "John F. Chandler" To: Christine M Gianone , Joe Doupnik , John Chandler , terry , Paul Placeway , Frank da Cruz Subject: Re: Labeled File Proposal In-Reply-To: cmg@watsun.cc.columbia.edu message of Thu, 16 Aug 90 13:24:14 EDT Message-Id: > have written draft 3, which embodies just about all of > those comments. Is it OK with everybody? I can see a lot of careful rewriting got done. It looks much better, but there are a couple of points that need clarifying. > SYSID The system ID, one of the codes listed on pp.275-278 of the Kermit > book. This is 1 to 99 characters long (but typically 1-3 > characters), for example "D7" for VAX/VMS. How about "This is a string of 1 to 99 ASCII characters (but ..."? You might as well mention ASCII in each definition for completeness. > The following labels > (composed of ASCII uppercase letters) are reserved: > > VERS - The operating system version, e.g. "5.3-1" I think this label should be not only reserved, but also required and, moreover, required to be first, even if the value has a zero length. This could (and should) be added to the criteria of the (optional) automatic label detector. Yes, I think zero-length values should be explicitly permitted right off the top. That possibility would otherwise be a lurking bug in some implementations. > DATA - This is the final label. What follows is the file's > contents, byte for byte. Maybe add "i.e., this label has no value, unlike all other labels"? Alternatively, it might be easier to explain if we don't make such an exception, and say instead DATA - This is the final label. It's value (see below) must have a length of zero. What follows that is ... > VALUE The value associated with the label, up to 999999999 bytes of 99999999 > The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many > labeled values are needed. If the DATA label has no VALEN, that exception should be repeated here for clarity. > DATA The file's data, as-is, byte-for-byte, as stored on the disk, not > preceded by a length field. The lack of a length field would be doubly clear if the above-mentioned amplifications were made concerning the "DATA" label. > No character set translation, record > format conversion, or any other modifications. Well, here is a problem. Complex structured files generally cannot be represented as a simple byte stream. In particular, storage on disk implies clumping the data into blocks or records, and perhaps into tracks and even into cylinders. Such clumping may (depending on the operating system) be an integral part of the file. Whenever the block lengths are not strictly bound to be all the same, the Kermit stream must include each block's length -- very much as in Kermit-370's V-BINARY type. I think you need to say "or any other modifications other than those specified or implied in the label information." > at all. In particular, a label-wise Kermit program can interoperate perfectly > well with another Kermit program that is completely ignorant of labeling, in > which case the latter program simply "archives" the file, labels and all. Add "(provided that the user remembers to place it in binary mode)." > USER INTERFACE It would be good to begin with a preamble that mentions up front that automatic label detection is a possibility. For example: "There are two possible modes of operation. The first (and safer) mode requires human intervention, but there may also be an automatic mode (see below)." > When SENDING a file, the user should first determine whether it is a bare file Begin "In the normal mode, when SENDING a file..." > The receiving Kermit program that has been given a SET FILE TYPE LABELED > command must inspect the incoming data. The first 24-30 bytes of the first 30-36 > packet contain the BANNER, the IDLEN, and the SYSID. IDLEN, SYSID, and the first LBLEN and LABEL. > If these three items are five If my suggestion of requiring the VERS label to be first is adopted, it's a trivial addition to check for the next six bytes after SYSID: they will always be "04VERS". For that matter, you could also inspect the first VALEN to make sure it's all ASCII decimal digits, but it's really a question of how failsafe you want the checking to be. Personally, I want it to be as safe as possible within reason because automatic label detection is such a nice feature. Anyway, adding that little extra check would mean 38-44 IDLEN, SYSID, and the first LBLEN, LABEL and VALEN. six > LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed. Is so, the default If > asks for it explicitly. For an arriving file, AUTOMATIC mode would detect the > BANNER and SYSID and go into action as if the user had SET FILE TYPE LABELED. , SYSID, and first LABEL and go... Gads, how did I manage to write so much? John