Columbia Kermit/kermit.zip/e/v11.1

Internet Message Format | 2020-01-01 | 21KB

From cmg  Thu Jan  4 18:25:07 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA03603; Thu, 4 Jan 90 18:25:07 EST
Date: Thu, 4 Jan 90 18:25:06 EST
From: Christine M Gianone <[e-mail]>
To: info-kermit
Subject: Info-Kermit Digest V11 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 4 Jan 1990        Volume 11 : Number 1

   PROPOSALS FOR KERMIT PROTOCOL ADDITIONS -

        Proposal for Kermit SET FILE COLLISION Command
        Proposal for Kermit SET ATTRIBUTE Command
        Proposal for REMOTE SET Extension to the Kermit Protocol

Digest submissions may be sent to [e-mail], requests
for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2.
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET the desired files.  The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e.  You can also get Kermit files
over BITNET/EARN; to get started send a message with text HELP to KERMSRV, the
Kermit file server, at host CUVMA.  For detailed instructions, read the file
kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Protocol Additions
Keywords: Kermit Protocol

This issue of the Info-Kermit Digest contains several proposals for extending
the Kermit protocol in certain minor ways, all of them related.  These
discussions are for Kermit developers.  They assume familiarity with the
Kermit protocol, as described in "Kermit, A File Transfer Protocol", by Frank
da Cruz, Digital Press (1987).

------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Proposal for Kermit SET FILE COLLISION Command
Keywords: Kermit Protocol, SET FILE Command

PROBLEM:

As pointed out by Gregg Wonderly in Info-Kermit V10 #4, as well as by John
Chandler (author of Kermit-370) and many others previously, Kermit's SET
WARNING (sometimes also known as SET FILE WARNING) command is misnamed and
furthermore does not allow for certain desirable kinds of behavior when a file
arrives which has the same name as an existing file.

SOLUTION:

A new command to replace the old SET [FILE] WARNING command (or which can
coexist with it): SET FILE COLLISION, similar to the SET FILE EXISTS command
which was proposed by Gregg.  The name was changed for grammar's sake, several
additional options are suggested, and their behavior described somewhat
differently:

SET FILE COLLISION REPLACE: Destroy the previously existing file, replace it
    with the new copy (the current behavior of SET WARNING OFF).

SET FILE COLLISION RENAME: Give the incoming file a new, unique name so that
    it won't overwrite any existing files (like SET WARNING ON).  This would
    be the default behavior.

SET FILE COLLISION BACKUP: Give the existing file a new, unique name, using
    the same algorithm that is used on the arriving file by SET FILE COLLISION
    RENAME, and then accept the incoming file under its own name.

SET FILE COLLISION DISCARD: Reject any incoming file that has the same name as
    an existing file using (a) the attribute refusal mechanism ("N" in the
    data field of the ACK to the Attribute packet) if the use of attribute
    packets was negotiated, (b) by putting an "X" in the data field of
    acknowledgements to any Data packets that arrive to request cancellation
    of the file.  Always use method (b), even if also using method (a), in
    order to get on to the next file as quickly as possible.  In case the
    sending Kermit does not understand either of these signals and the file
    continues to arrive, do not open a new file and simply acknowledge and
    discard all data packets up to the end of the file.

    As Gregg pointed out, the DISCARD option will be handy for resuming
    transfer of a file group that had been interrupted.  This gives us a cheap
    version of checkpointing.  A more general and protocol-driven
    checkpointing mechanism will be proposed in the future.

SET FILE COLLISION APPEND: Append an arriving file to an existing file
    that has the same name.  The resulting file keeps the same
    system-dependent characteristics it had before, except that the date is
    changed.  This option should be used with caution, since it opens the
    door to creating files of mixed types (e.g. a text file appended to a
    binary file, a spreadsheet appeneded to a database, etc).  Old versions
    of IBM mainframe Kermit operated in this way.

SET FILE COLLISION ASK: Ask the user whether to replace, rename, discard,
    or append each arriving file that has the same name as an existing file.
    This option, too, should be used with caution because the file transfer
    could time out if the user takes too long to answer the query.  There are
    also user-interface issues: what happens to the active file transfer
    display, etc.  Macintosh Kermit currently supports this in the form of
    of "attended file transfer mode".

When the REPLACE and BACKUP options are in effect, a question arises
(originally posed by John Chandler).  Should the receiving Kermit create the
new file using its current file settings (SET FILE TYPE, etc), or should the
new file inherit the characteristics of the existing file, like protection,
blocksize, record format, etc, on systems where files have such things (IBM
mainframes, VAX/VMS, etc)?  There should also be a command to let the user
specify this:

SET FILE REPLACE {PRESERVE, DEFAULT}

where PRESERVE would create the new file with the same characteristics as the
old one, and DEFAULT would use the current file settings of the receiving
Kermit program and the host operating system when creating the new file.

The setting of SET FILE COLLISION will have an effect (as FILE WARNING does
now) upon the receiving Kermit's handling of the file size attribute as
reported in the incoming Attribute packet.  If the REPLACE option is in force,
then the existing file's size must be added to the available space before
deciding whether to accept or refuse the file on the basis of space.

This new command involves no new protocol.  Its operation is strictly local
to the receiving Kermit program, and gives the user added control over its
behavior when receiving files.

------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Proposal for Kermit SET ATTRIBUTE Command
Keywords: Kermit Protocol, SET ATTRIBUTE Command

PROBLEM:

As the use of File Attribute (A) packets within Kermit programs grows more
widespread, it is becoming apparent that the user needs to have more control
over this feature.  Currently, most Kermit programs that support attribute
packets have a command SET ATTRIBUTES {ON, OFF}, so that if one or more
attributes is causing problems on the receiving computer, the sender can be
commanded not to send any attributes at all and the receiver can be told to
ignore all incoming attributes.

For example, suppose both the sender and receiver programs support the file
creation date attribute, and the receiver sets the arriving file's date from
it.  On some computers, incremental backups work according the file date and
so files that are received by Kermit won't be backed up.  If the user gives
the SET ATTRIBUTES OFF command, then the current date will be used when
creating the incoming file, but other useful attributes like file size will be
absent or ignored.  In this case, the receiving Kermit will not be able to
reject an arriving file in advance if it would be too big to fit on the
available storage.

You should not have to sacrifice all file attributes if only one of them is
causing problems.  Furthermore, it is possible to imagine situations in which
you want a certain attribute to be effective when sending a file but not when
receiving, or vice-versa.  For example, suppose the date attribute works
correctly when receiving a file, but when sending a file it causes the other
Kermit program to crash because of a bug.  In this case, you need a way of
telling your Kermit program to not to send the date attribute, but still
continue to handle for incoming files.

SOLUTION:

A new command, SET ATTRIBUTE <name> {IN, OUT} {ON, OFF}.  The <name> is the
name of any Kermit attribute as listed on pp.272-279 of the Kermit book, or
else the word ALL to mean all attributes.  IN OFF means that the attribute
should be ignored if it appears in an incoming File Attribute packet.  OUT OFF
means that the named attribute should not be included in any File Attribute
packets which are sent.  IN ON and OUT ON are used to enable the named
incoming or outbound attributes.  If you specify ALL OFF, then the Kermit
program should not set Attribute bit in the capabilities field of its
Send-Init packet (equivalent to the current command SET ATTRIBUTES OFF).
Examples:

  Command                      Meaning

  SET ATTRIBUTE LENGTH IN OFF  Ignore incoming length attributes
  SET ATTRIBUTE DATE OUT OFF   Omit date from outbound attributes
  SET ATTRIBUTE DATE OUT ON    Include date from outbound attributes
  SET ATTRIBUTE ALL OUT OFF    Don't send any attributes
  SET ATTRIBUTE ALL IN OFF     Ignore all incoming attributes

This new command is completely self-contained within each Kermit program.
There is no additional protocol between the two Kermit programs.

Thanks to John Chandler and Joe Doupnik for advice and suggestions on these
new commands.

------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Proposal for REMOTE SET Extension to the Kermit Protocol
Keywords: Kermit Protocol, REMOTE SET Command

PROBLEM:

Certain Kermit programs (including MS-Kermit 3.0, C-Kermit 4F) include
information about whether a file is text or binary in the File Attribute
packet, so the receiver can put itself into the right mode automatically.  But
when talking to a server there is no way for the client program, before
issuing a GET command, to tell the server whether to send the file in text or
binary mode.  This problem extends to various other protocol and file-related
parameters.

NOTE:

The Kermit protocol definition includes a REMOTE KERMIT command, and the
associated packet format and protocol.  It lets the user of the client program
issue a command to the server in its own interactive-mode command language.
But this is not a totally satisfactory answer because the syntax of Kermit
programs can and does vary and, perhaps more to the point, some Kermit
programs do not have an interactive command mode at all (Macintosh Kermit is
one example).  What is needed is a standard mechanism and syntax that can
apply to all Kermit programs uniformly.

SOLUTION:

A new addition to the Kermit protocol: REMOTE SET.

REMOTE SET would be a Generic Kermit Server command.  A generic command looks
like this:

    +-----+---------------------------------+
    |  G  | x <len1> <op1> <len2> <op2> ... |
    +-----+---------------------------------+
     Type   Data

where "x" is the generic command, a single letter.  The letter S is not yet in
use, so let's define S to mean SET.  The S is followed by a single operand,
which includes a single-character length field, similar to other generic
command packets.

The parameters which may be SET remotely are the ones having to do with file
transfer and Kermit protocol in general, not system-dependent or
communications-dependent parameters, since these must already have been set
prior to making the initial connection, and must be set correctly in any event
BEFORE you can successfully send a REMOTE SET (or any other) packet to the
server.

The most needed REMOTE SET command is REMOTE SET FILE TYPE {TEXT,BINARY}, but
the others should be specified in the protocol too.  Numeric codes are
assigned to the parameters and values, so that the mechanism for conveying
this information is system- and language-independent and reasonably compact.
The REMOTE SET command does exactly what the corresponding SET command would
do if it had been given to the remote server as an interactive command before
it entered server mode.

  Command                                Code   Values

  REMOTE SET ATTRIBUTES IN ALL            132   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN LENGTH         133   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN TYPE           134   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN DATE           135   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN CREATOR        136   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN ACCOUNT        137   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN AREA           138   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN BLOCK-SIZE     139   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN ACCESS         140   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN ENCODING       141   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN DISPOSITION    142   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN PROTECTION     143   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN GPROTECTION    144   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN SYSTEM-ID      145   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN FORMAT         146   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN SYS-INFO       147   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN BYTE-COUNT     148   0 = OFF, 1 = ON

  REMOTE SET ATTRIBUTES OUT ALL           232   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT LENGTH        233   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT TYPE          234   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT DATE          235   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT CREATOR       236   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT ACCOUNT       237   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT AREA          238   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT BLOCK-SIZE    239   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT ACCESS        240   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT ENCODING      241   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT DISPOSITION   242   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT PROTECTION    243   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT GPROTECTION   244   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT SYSTEM-ID     245   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT FORMAT        246   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT SYS-INFO      247   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT BYTE-COUNT    248   0 = OFF, 1 = ON

  REMOTE SET FILE TYPE                    300   0 = TEXT, 1 = BINARY
  REMOTE SET FILE NAMES                   301   0 = CONVERTED, 1 = LITERAL
  REMOTE SET FILE COLLISION               302   0 = RENAME,  1 = REPLACE,
                                                2 = BACKUP,  3 = APPEND,
                                                4 = DISCARD, 4 = ASK
  REMOTE SET FILE REPLACE                 303   0 = PRESERVE, 1 = DEFAULT
  REMOTE SET FILE INCOMPLETE              310   0 = DISCARD, 1 = KEEP
  REMOTE SET INCOMPLETE (same as above)

  REMOTE SET BLOCK-CHECK                  400   number (1, 2, or 3)
  REMOTE SET RECEIVE PACKET-LENGTH        401   number (10-9024)
  REMOTE SET RECEIVE TIMEOUT              402   number (any, 0 = no timeout)
  REMOTE SET RETRY                        403   number (any, 0 = no limit)
  REMOTE SET SERVER TIMEOUT               404   number (any, 0 = no timeout)
  REMOTE SET TRANSFER CHARACTER-SET       405   Character Set Designator
  REMOTE SET WINDOW-SLOTS                 406   number (1-31)

One Kermit program should not have knowledge of another Kermit program's local
character sets, therefore REMOTE SET FILE CHARACTER-SET is not included.  The
Transfer Character Set Designator is the one described in the "ISO/Kermit"
proposal.  For example "I2/100" (ISO Latin Alphabet 1), "I2/144" (ISO
Latin/Cyrillic), or "I14/13" (Japanese Roman/Katakana).  The command would
use the name (for example REMOTE SET TRANSFER CHARACTER-SET LATIN1) and the
generic server command packet would use the corresponding designator.

REMOTE SET LANGUAGE is omitted for the present, but can be added later.  The
problem here is assigning a unique code to each of the world's languages.

The numbers shown for the codes and values are expressed as character
strings composed of ASCII digits, 0-9.  Here are examples, showing the TYPE
and DATA fields of the Kermit packet:

  GS#101!0      = REMOTE SET ATTRIBUTE LENGTH OFF
  GS#202!0      = REMOTE SET ATTRIBUTE TYPE OFF
  GS#300!1      = REMOTE SET FILE TYPE BINARY
  GS#400!2      = REMOTE SET BLOCK CHECK 2
  GS#401$1000   = REMOTE SET RECEIVE PACKET-LENGTH 1000
  GS#405&I2/100 = REMOTE SET TRANSFER CHARACTER-SET LATIN-1

ORGANIZATION AND EXPANSION:

The codes are numeric strings, with the hundred's place assigned roughly
according to "topic": 100's for Incoming Attributes, 200's for Outbound
Attributes, 300's for file-related items, and 400's for packet-related items.
Note that the SET ATTRIBUTE codes are equal to 100 or 200 plus the value of
the corresponding attribute designator.  There is plenty of room for expansion
within each category, and new categories can be added as required.

PROTOCOL:

The person using the client Kermit program issues a REMOTE SET command for
a single parameter, such as REMOTE SET FILE TYPE BINARY.  The program forms
the corresponding G packet and sends it to the server.

The server program can respond in any of the following ways, and the client
program should be prepared for each kind of response:

  E-packet:  An Error packet.  The server does not understand REMOTE SET
             packets, or it is not able to perform the specific SET that was
             requested.  Therefore the client must not assume that the SET has
             been done, and if it is in local mode, it must give a message to
             the user, as described below.

  Y-packet:  An Acknowledgement.  The server accepted the command, and
             performed the requested SET.  The data field of the Y-packet can
             be empty, to indicate that the requested value was accepted.  Or
             it can contain the value which the server actually set.  For
             example, the user types REMOTE SET RECEIVE PACKET-LENGTH 5000 but
             the server only supports lengths up to 1000:

        To server -->  GS#400$5000
                   Y1000        <-- To client

CLIENT IMPLEMENTATION:

A client can include support for any number of the REMOTE SET commands, or
none at all.  A minimal implementation might include only REMOTE SET FILE
TYPE.  This would include addition of the command to the program's command
tables, code to send the generic packet, and code to interpret the response
and issue any appropriate messages to the user, like the contents of the
error packet data field, or any altered value that the server sent back in
the data field of an acknowledgement.  Examples:

    REMOTE SET command succeeded
    REMOTE SET value changed to 1000
    REMOTE SET command failed: <reason from data field of E-packet>

SERVER IMPLEMENTATION:

A server can also include support for any number of the REMOTE SET commands,
or none at all.  If it supports none at all, then it will automatically
respond to a REMOTE SET packet with an error packet containing a message
like "Unimplemented REMOTE command".

If the server receives a REMOTE SET packet for a parameter it does not support
the REMOTE SETting of, then it should respond with an error packet containing
the message "Unknown REMOTE SET parameter".

If the server gets a REMOTE SET packet for a parameter which is known to it,
then it should:

(a) Set the parameter to the requested value and respond with an empty Y
    packet, or:

(b) If the requested value exceeds the server's maximum value for the
    parameter, set it to its own maximum value and respond with a Y packet
    containing the new value in its data field, as in the packet-length
    example above.

If the server is a "permanent" Kermit server which cannot be terminated using
BYE or FINISH, then when the user disengages from it using BYE, FINISH, or
LOGOUT, then when the server receives a BYE, FINISH, or LOGOUT command, it
should revert any parameters that were changed by REMOTE SET back to the
values that were in use when server mode was entered.

Thanks to Joe Doupnik and John Chandler for their assistance in the design
of this protocol extension.

------------------------------

End of Info-Kermit Digest
*************************