Columbia Kermit/kermit.zip/protocol/whatami.txt

Text File | 2020-01-01 | 11KB | 237 lines

WHATAMI  -  DRAFT #4

Wed Jun 15 15:38:11 1994
Amended: Thu Nov 27 19:32:33 1997

Those who are accustomed to using client/server applications such as FTP
expect that certain kinds of commands, when given to the client, will affect
the server correspondingly.  Most notable among these commands (in FTP's case)
are those that set the transfer mode: BINARY, ASCII, TENEX, etc.

In Kermit, however, the transfer mode is determined by the file sender, a
concept totally unrelated to the client/server distinction, and
counterintuitive to most people.  Furthermore, Kermit programs do not always
have a client/server relationship -- there is also the send/receive
arrangement.

It might be desirable, when two Kermits are indeed client-and-server, for the
CLIENT's file-transfer mode to be used rather than the FILE SENDER's.

On the positive side, this would make Kermit more like FTP and, for that
matter, "less astonishing" to most users -- in English, one expects a "server"
to honor the wishes of a "client".  We have had many complaints from users who
put the remote Kermit in server mode, escaped back, told the local Kermit to
"set file type binary", then "get foo.zip", and were rudely surprised to find
the file was transferred in text mode.

On the other hand, this would be a change in behavior.  There might be users
who actually depend on the current behavior, e.g. so that files will be sent
to the server in binary mode, but retrieved *from* the server in text mode or
vice versa.

On balance, it seems better to make the change -- another case of doing what
the majority of users would expect, rather than catering to a small (perhaps
nonexistent) minority.  Should the minority exist at all, they can still
determine the transfer mode by giving SET FILE TYPE commands to the client.

Would it be desirable to extend this notion to the send/receive relationship?
No, it would not.  In that case, there would be no criterion at all for
settling a disagreement.  So in this case, traditional rules should prevail.

FEATURES

Two settings could be handled by WHATAMI: the file transfer mode (text or
binary) and the filename conversion method (converted [analogous to text] and
literal [analogous to binary]).

All other settings are either negotiated or conveyed already, or else they
are not appropriate for this type of treatment (because, for example, there is
no reason that they should always be the same in both Kermits).

The WHATAMI information will allow two Kermit programs to tell whether they
have a client/server relationship, and if so, to allow the file transfer mode
and name conversion to be determined by the client rather than the file sender.

IMPLEMENTATION

The following following fields remain reserved in the initialization string
for Checkpoint/Restart:

  CAPAS+4, CHKPNT, 1 byte: WILL (1), WONT (0), DO (2)
  CAPAS+5, CHKINT, 3 bytes: Checkpoint interval

In the absence of Checkpoint/Restart capability, these fields should be
filled in as follows:

  CHKPNT: "0"      (Character 0 = WONT)
  CHKINT: "___"    (Three underscores)

CAPAS+8 will be the WHATAMI field, with room for 6 bits of information.  This
is a binary 6-bit quantity which will be encoded for transmission via tochar()
and decoded after reception via unchar() (functions which add and subtract 32,
respectively).  The items are simple on/off items corresponding to commands
that, in a client-server environment, one would expect to take effect for
subsequent file transfers:

  SET FILE TYPE { TEXT, BINARY }
  SET FILE NAMES { CONVERTED, LITERAL }

The layout of the (unencoded) WHATAMI field is:

    Bit 5    Bit 4          Bit 3       Bit 2    Bit 1    Bit 0
  +--------+--------------+-----------+--------+--------+--------+
  |     1  | CLEARCHANNEL | STREAMING | FNAMES | FMODE  | SERVER |
  +--------+--------------+-----------+--------+--------+--------+

where:

  Bit 5
    Is set to 1 to indicate that the other bits are to be believed.
    This allows this field to be skipped over in the event it is not
    implemented, but a subsequent field is added.

  CLEARCHANNEL:
    Is set to 1 if I know I have a 100% transparent end-to-end
    communications channel (except, possibly, for the 8th bit).

  STREAMING:
    Is set to 1 if I know I have a reliable transport (see Streaming spec).

  NAMES:
    My SET FILE NAMES setting
      0 = LITERAL (unconverted)
      1 = CONVERTED (normal)

  FMODE
    My global file transfer mode (SET FILE TYPE):
      0 = TEXT
      1 = BINARY

  SERVER:
      0 = I am not in server mode
      1 = I am in server mode

ACTIONS

Every Kermit program that implements the WHATAMI feature shall set its WHATAMI
field (as well as the intervening, but as-yet-unused, checkpoint-related
fields) in the initialization string.  This is purely a matter of reporting:
Here's What I Am.

Furthermore, all WHATAMI-capable Kermit programs should also send I-packets
at the beginning of each protocol transaction when acting as clients, rather
than only sending them when settings have changed.

Kermit programs that implement this feature shall keep a "What Are You"
variable that contains the WHATAMI information most recently received from
the other Kermit.  This variable is initialized to zero at the beginning of
each protocol transaction.

When a Kermit program receives an initialization string containing a WHATAMI
field, it saves the value of this string in its "What Are You" variable.
Since Bit 5 of a valid WHATAMI field is always set, this distinguishes the
initial value of zero from any legitimate WHATAMI value.

Now, when a Kermit server receives a GET (R) packet, it checks its What Are
You variable, and if Bit 5 is set, then it sets its global file transfer mode
and name conversion according to bits 1 and 2, respectively.  Note that these
global modes can still be overridden on a per-file basis in the normal way;
the server will always respond to REMOTE commands in text mode, no matter what
its global transfer mode; a VMS C-Kermit server will always determine a file's
transfer mode based on its RMS characteristics, etc.

That's about it.  When the client gives SEND or MSEND commands, everything
behaves well already, and WHATAMI won't change that.  Ditto for REMOTE
commands.  Other uses can be imagined for WHATAMI (besides as a condiment for
sushi) but they are only frills -- detecting mode mismatches and issuing more
intelligent error messages, etc.  Nothing earthshaking.

Finally, here is a sample dialog between two Kermits who have the WHATAMI
feature.  The remote Kermit starts out in server mode and in text mode, the
local Kermit client is in binary mode, seen from the client's point of view:

  s-^A5 I~* @-#Y3~^$5$0___FO    F = Names converted, binary mode, client
  r-^A5 Y~* @-#Y3~^$5$0___E^    E = Names converted, text mode, server
  s-^A& Rx.xX                   Client says "get x.x"
  r-^A5 S~* @-#Y3~^$5$0___GZ    G = Names converted, binary mode, server
  s-^A5 Y~* @-#Y3~^$5$0___F_    F = Names converted, binary mode, client
  r-^A(!FX.X+ /
  s-^A(!Yx.x.-N
  r-^AG"A."U1""B8#119940608 21:02:22!!11"98,1/   <--  Note "B8".
  s-^A%"Y.5!

etc etc.

COMPATIBILITY

Let's use the word "smart" to refer to a Kermit program that has WHATAMI
capability, and examine the four possible combinations of client and server:

     CLIENT   SERVER
  1. Smart    Smart
  2. Smart    Not
  3. Not      Smart
  4. Not      Not

Case 1 behaves in the new way described above.  Cases 3 and 4 behave in the
traditional (pre-smart) manner.  Case 2 is problematic, since the user might
expect local file-type or -naming changes to also be effective at the server,
and they won't be.

Let's consider case 2.  When the client receives a reply to its I packet and
finds no WHATAMI info, it can:

 1. Issue a warning message to the effect that ... "The server does not
    follow local settings for binary and text file transfers.  If it is not
    in <current-local-mode> mode already, you should interrupt this transfer,
    FINISH the server, put it in <current-local-mode>, and start again."  But:
    (a) this is a big message -- we generally only have room for one-liners
    on the file transfer display screen; (b) many times the message won't be
    necessary because the user already *has* put the server into the right
    mode, and so (c) they will want yet-another-SET-command to disable such
    messages.  And (d) a good proportion of users won't have the slightest
    idea what the message means anyway.

 2. Automatically send a REMOTE SET FILE TYPE BINARY command packet.  But this
    might not work either because the server might not support REMOTE SET
    either.  In which case the client can print a warning message and (a)
    proceed with the transfer (which will be wrong if the server is in text
    mode); (b) cancel the transfer with an E packet (which could be wrong if
    the server was in binary mode); or (c) ask the user (which would be wrong
    because it would break lots of scripts).

A third possibility would require a new SET command:

  SET TRANSFER MATCH-TYPE { ON, OFF }

(for want of a better name that is not ridiculously long...) which means:

  If I am a client and the other Kermit is a server, and it sends me a file
  in text mode, but I'm in binary mode, or vice versa, then I should cancel
  the transfer with an Error packet.

But that's no good either, because if the server is not smart, the client
won't know it's a server, and furthermore, it will do no good anyway if the
server is not using Attribute packets, in which case we won't have a clue
about the transfer mode of the incoming file anyway.

So, after considering the possibilities, I think it might be best to let
sleeping dogs lie.  If a GET command fails to transfer in the right mode, we
are no worse off than we were before; if it works right, nobody will be the
wiser about why.  "Keep it simple for the average user" -- our motto.  Let the
experts fend for themselves, as they always have done anyway.

In fact, just to be safe, we have always told people to "set file type binary"
(or whatever) on BOTH ends, since we can't rely in every case on the various
forms of automatic transfer-type notification.  If they follow that advice,
they'll be in good shape.  If they don't, the new stuff will tend to help them
out in many cases -- notably the ones where they are running the latest
versions of *our* software.

The only change I'd recommend would be to print TEXT or BINARY on the file
transfer screen all caps for emphasis.  They can also see the interruption
instructions down below on the same screen in case they notice that the
transfer mode is not what they wanted.

(End of WHATAMI DRAFT)