WHATAMI

A big problem with Kermit protocol & software is that it can be in so many
different (combinations of) "modes" -- local, remote, client, server, etc etc,
and users are understandably confused about where to give which command under
what conditions -- the sender determines the file type, the receiver
determines the packet length, the client can't send a GET or REMOTE or FINISH
command unless the other Kermit is in server mode, etc.

Suppose the negotiation string (S and I packet + ACK) included a new field,
"WHATAMI" containing the following information:

Client vs Server mode?
  I am in server mode; I am not in server mode - 1 bit.

Current (global) file transfer mode
  Text or binary - 1 bit.

Once having exchanged I or S packets, each Kermit knows which mode the other
is in.  If the client knows it's talking to a server and (a) the connection is
still open, and (b) a BYE or FINISH command has not been given, and maybe (c)
a CONNECT command has not been given, the client can act more like a client --
SET commands affecting certain parameters (block check, ...) can take effect
at both ends simultaneously, just like with an FTP client and server.  A
RECEIVE command can give an error message right away.  We could even have a
way to set or change the default destination for commands like DIR, DEL, TYPE,
CD, etc -- to have them take effect locally (as now) or at the server (as in
FTP).

Implementation: The following remain reserved 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)
  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
by adding 32 (SP).  The items here are simple on/off items corresponding
to commands that, in a client-server environment, one would expect to take
effect for forthcoming transfers:

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

The layout of the of the WHATAMI field is like this:

    Bit 5    Bit 4    Bit 3    Bit 2    Bit 1    Bit 0
  +--------+--------+--------+--------+--------+--------+
  | xxxxxx | xxxxxx | xxxxxx | SERVER | NAMES  | BINARY |
  +--------+--------+--------+--------+--------+--------+

where:

xxxxxx = Reserved, and:

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

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

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

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

Whenever a Kermit transaction takes place, each Kermit makes a note of the
other's "modes", and...

 1. Local Kermit client, remote Kermit server in text mode.
    Client user says SET FILE TYPE BINARY, GET OOFA.ZIP.
    At I-packet time, server sees that client wants a binary transfer,
    and so saves its global mode, switches to binary, sends the requested
    file(s) in binary mode, then restores its global mode, user gets the
    expected binary transfer.

 2. Like (1), but with SET FILE NAMES LITERAL, same deal.

 3. Local Kermit client, remote Kermit in RECEIVE mode.
    Client user says REMOTE HELP or other command-for-server.
    Client Kermit sends I-packet, remote Kermit sends ACK saying I Am Not
    A Server, local Kermit knows immediately to give up and can tell the
    user why.

 4. Local Kermit client, remote Kermit in SEND mode.
    Client user says GET blah, thinking that GET is the same as RECEIVE.
      Remote sends S.
      Local sends I.
      Remote sends E and quits, which is proper.
      Local ignores E because of "the rule", and sends R.
      There is no response, so local times out & resends R lots of times.
    WHATAMI doesn't help here.  But the SENDer could retransmit the S
    packet instead of sending an E-packet, which would make the GETter
    diagnose a fatal error.