home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
archives
/
protocol.tar.gz
/
protocol.tar
/
digest-1989.txt
< prev
next >
Wrap
Text File
|
1989-12-14
|
21KB
|
412 lines
Info-Kermit Digest Wed, 13 Dec 1989 Volume 10 : Number 5
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 Info-Kermit@WATSUN.CC.COLUMBIA.EDU,
requests for addition to or deletion from the Info-Kermit subscriber list to
Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET.
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. 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 <cmg@watsun.cc.columbia.edu>
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 <cmg@watsun.cc.columbia.edu>
Subject: Proposal for Kermit SET FILE COLLISION Command
Keywords: SET FILE COLLISION Command
PROBLEM:
As pointed out by Gregg Wonderly in Info-Kermit V10 #4, as well as by John
Chandler 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), to
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 options 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, author of Kermit-370). 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 <cmg@watsun.cc.columbia.edu>
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 <cmg@watsun.cc.columbia.edu>
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
"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 assistance with the design of this
protocol extension.
------------------------------
End of Info-Kermit Digest
*************************