Columbia Kermit/kermit.zip/archives/protocol.zip/tagged2.txt

Text File | 1990-08-16 | 9KB | 180 lines

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

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 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.

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 24-30 bytes of the first
packet contain the BANNER, the IDLEN, and the SYSID.  If these three 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.  Is 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 and SYSID 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.

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.