Kermit programs presently differentiate between text and binary files via the SET FILE TYPE command. When the file type is TEXT, the Kermit program that is sending the file converts the file's record format and character set from its local form to a standard form, and the receiving Kermit program converts from the standard form into its own local record format and character set. When the file type is BINARY, the file is sent as-is, byte for byte. These two ways of handling files are sufficient in many cases, but fall short when one or both computers has a complex file system, such as the Macintosh or DEC operating systems like VAX/VMS. The Kermit protocol includes a mechanism for transmitting a file's attributes in a generic way, but these attributes are of little use when the file is being received by a computer with a simple file system, such as UNIX or MS-DOS, that can't do anything with them. And they are not sufficient to convey every conceivable bit of information about about every kind of file on every kind of computer. To allow a complicated file to be transferred, a new file type is proposed: SET FILE TYPE LABELED Notice the spelling of "LABELED" (only one L between the E's). When this setting is in effect, the sending Kermit sends not only the file's data, but also system-dependent structural information about the file. Since this information can be quite lengthy, it is sent as if it were file data, in data packets preceding the actual file data, rather than in attribute packets. All of this information is sent in binary mode (no conversions). The receiver of the file can elect whether to act upon the label information, or simply store it. Kermit programs for simple file systems need no changes, and can still act as repositories for labeled files, to be sent back later to the system of origin. On the other hand, labeled file transfers between like systems (e.g. two VAX/VMS computers) will result in the reception of a file with all the correct characteristics. There are two possible modes of operation. The first (and safer) mode requires human intervention on a per-file basis, but an automatic mode is also possible. DEFINITIONS A "bare" file is a file stored on disk that does NOT contain, as part of its contents, Kermit-constructed label information. A "labeled" file is a file stored on disk whose contents include Kermit-constructed label information. FORMAT OF A LABELED FILE This description applies to a labeled file as stored on disk and to a bare file that has label information added to it by a sending Kermit. BANNER The literal text string "KERMIT LABELED FILE:", just the twenty characters within the quotes including the trailing colon, in 7-bit ASCII. ASCII is used even on non-ASCII systems (like IBM mainframes with EBCDIC). IDLEN A 2-byte ASCII decimal numeric length field, with leading zeros if necessary, for example "02". SYSID The system ID, one of the codes listed on pp.275-278 of the Kermit book. This is a string of 1 to 99 ASCII characters (but typically 1-3 characters), for example "D7" for VAX/VMS. The length of the SYSID field is given by the preceding field (IDLEN). LBLEN A 2-byte ASCII numeric length field, with leading zeros if necessary, for example "00", "02", "09", "99". LABEL A label field, 1 to 99 ASCII characters. The length is given by the preceding length field (LBLEN). The LABEL field contains the name of the file descriptor data that follows. VALEN An 8-byte ASCII numeric length field, with leading zeros if necessary, for example "00000512". Zero ("00000000") is a permissible length for a value. VALUE The value associated with the label, 0 to 99999999 bytes of information about the file in system-dependent format. The labels and the format and layout of the associated values for each system type should be clearly defined and documented. The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many labeled values are needed (if VALEN is zero, then VALUE is omitted). CONTENT The file's contents, encoded in whatever form that, in combination with the labeled values, allows for its eventual reconstruction in its original form. REQUIRED LABELS The following labels (composed of ASCII uppercase letters) are reserved, and are required in every labeled file: VERS The operating system version, e.g. "5.3-1" DATA This is the final label. It has a zero-length value, which is followed immediately by the file's contents, as defined above. See example below. EFFECTS ON THE KERMIT PROTOCOL When SET FILE TYPE LABELED is in effect, the sending Kermit should include the file type (") attribute, specifying a type of binary (B), if attribute packets have been negotiated. Otherwise, there is no effect on the protocol 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. This proposal does not rule out the system-independent type of file archiving, based on file attribute packets, that is described in the Kermit book. However, if the "system-dependent" attributes suggested by this proposal can be worked out in a sufficiently generic fashion, this may lead to a more effective type of transmission of complex files between unlike systems that share similar types of file characteristics (block size, record format, character set, carriage control, etc). On the other hand, for the first pass at an implementation (for VMS), it might make more sense to simply have a single system-dependent label, like "FAB", whose value is simply the File Access Block, and perhaps another one like "ACL" for its Access Control List. The two approaches do not rule each other out. USER INTERFACE When SENDING a file, the user should first determine whether it is a bare file or a labeled file. This can be done by visual inspection (looking at the first 20 bytes), or from memory (e.g. because all labeled files have a particular filetype, or are kept together in a certain directory). Then: (a) If it is a bare file, use SET FILE TYPE LABELED if you want to send label information too. (b) If it is a labeled file, use SET FILE TYPE BINARY. When receiving a file, use SET FILE TYPE LABELED if you want labels in the incoming file to be interpreted and applied, and: (a) The other Kermit is sending a bare file from a like system using SET FILE TYPE LABELED, or: (b) The other Kermit is sending a labeled file, of the receiving system's system type, from any kind of system, without SET FILE TYPE LABELED. The receiving Kermit program that has been given a SET FILE TYPE LABELED command must inspect the incoming data. The first 30-36 bytes of the first packet contain the BANNER, IDLEN, SYSID, and the first LBLEN, and LABEL (which should be "04VERS"). If these five items are in correct format, and the SYSID matches the program's own, then the program will accept the file in labeled mode. Otherwise, it will treat it as a binary file and store all the data, including BANNER, SYSID, LABELs, VALUEs, and all length fields. If a receiving Kermit program has accepted the file in labeled mode, but then encounters an unknown label or other inconsistency in the labeled file format, it must interrupt the file transfer (by putting an X in the data field of the first available ACK) and discard the file. This is because it cannot be expected to back up and undo whatever label interpretation it has already done. It is also conceivable that "similar" systems -- such as the DEC operating systems VMS and RSX-11 -- might be able to honor each other's labels. This eventuality should be allowed for, possibly with SET commands. At the discretion of the programmer, a command such as SET FILE LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed. If so, the default must be MANUAL, that is, processing of labeled files occurs only if the user asks for it explicitly. For an arriving file, AUTOMATIC mode would detect the BANNER, SYSID, and first LABEL and go into action as if the user had SET FILE TYPE LABELED. When sending a file, the program would avoid adding surrounding label information if the user had already SET FILE TYPE LABELED. This sort of thing is obviously dangerous, and users should be cautioned about it. EXAMPLE A hypothetical example for VMS (ignore the indentation and line breaks); the length fields are marked with L's: LL LL LLLLLLLL LL LLLLLLLL KERMIT LABELED FILE:02D704VERS000000055.3-103FAB00000512<512 bytes here> 03ACL00000723<723 bytes here>02DATA00000000 LL LLLLLLLL LL LLLLLLLL Note: FAB and ACL are not necessarily real labels. POSTPROCESSING Separate programs should be provided to translate a labeled file into a real file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file was deposited by means other than Kermit. Such a program might have two options (or come in two forms): interpret the labels, and simply strip the labels. ACKS Thanks to Terry Kennedy and Frank da Cruz for suggesting this idea, and to Joe Doupnik, John Chandler, and Paul Placeway for many valuable suggestions.