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

Text File | 2020-01-01 | 19KB | 412 lines

24-Jun-94 15:04:54-GMT,2236;000000000005
Received: by watsun.cc.columbia.edu id AA23458
  (5.65c+CU/IDA-1.4.4/HLK); Fri, 24 Jun 1994 11:04:44 -0400
Date: Fri, 24 Jun 94 11:04:43 EDT
From: Frank da Cruz <[e-mail]>
To: Mike Freeman <[e-mail]>
Subject: Re: C-Kermit "Feature?"
In-Reply-To: Your message of Fri, 24 Jun 94 10:51:18 EDT
Cc: Bo Kullmar <[e-mail]>
Message-Id: <[e-mail]>

> Hi, Frank.
>
> I have put commands like:
>
> remote set file type binary
> get ~kermit/test/bin/cku190.tar.gz
>
> into a "take-file" and tried to execute using C-Kermit for Vax/VMS
> (Alpha 18).  Unfortunately, the incoming files have attribute "text" as
> if the "remote set" hadn't taken effect.  Am I doing something wrong or
> do we have a "feature" here?  BTW, a "remote set file type binary"
> works in interactive mode.
>
This is very hard to explain, but I think it's a feature.

Many people in the past have complained about the following scenario:

1. Start Kermit on remote end and put it in server mode.

2. Escape back to local Kermit, "set file type binary", and "get" a file.

They expect the file to be transferred in binary mode, but it comes in text
mode.

The new feature, which so far appears only in C-Kermit 5A(190), called
"WHATAMI", works like this:

If both Kermits support WHATAMI, and they have a client-server relationship,
then the client's file-transfer mode (and file names conversion setting)
predominates, rather than the file sender's.

Obviously there are disadvantages to the old approach (file sender determines
the file transfer mode) -- it is hard to explain to most people.  They want
Kermit to work like FTP.  I was hoping that the new method would work right
more often for more people than the old method.

But obviously, since you are familiar with the old method, it took you by
surprise.

I am not sure what to do about this.  I can back off and remove the new
feature, which would be bad for new users, or I can publicize it better (which
would confuse new users but inform old users), or add Yet Another SET command
to turn it on or off, but that would do no good for new users who would not
understand what it is for anyway.

What's your opinion?

- Frank

24-Jun-94 15:26:16-GMT,2597;000000000015
Received: by watsun.cc.columbia.edu id AA24836
  (5.65c+CU/IDA-1.4.4/HLK); Fri, 24 Jun 1994 11:26:15 -0400
Date: Fri, 24 Jun 94 11:26:10 EDT
From: Mike Freeman <[e-mail]>
To: Frank da Cruz <[e-mail]>
Subject: Re: C-Kermit "Feature?"
In-Reply-To: Your message of Fri, 24 Jun 94 11:04:43 EDT
Cc: [e-mail]
Message-Id: <[e-mail]>

> Obviously there are disadvantages to the old approach (file sender determines
> the file transfer mode) -- it is hard to explain to most people.  They want
> Kermit to work like FTP.  I was hoping that the new method would work right
> more often for more people than the old method.
>
Makes considerable sense.
>
> But obviously, since you are familiar with the old method, it took you by
> surprise.
>
That it did!  I had discovered since I sent you the message exactly
the behavior you describe; i.e., what-am-i implies Kermit
works like FTP.  Being a Kermit veteran, as you say, caused
me to expect the "old" behavior; being a mainframe programmer
leads me to expect about eight different behaviors depending
upon the comm package I'm using :-).  I don't say, though, that
such a profusion of syntaxes is ideal.

In any event, once you pointed the feature out/I discovered it
myself, it makes sense.
>
> I am not sure what to do about this.  I can back off and remove the new
> feature, which would be bad for new users, or I can publicize it better (which
> would confuse new users but inform old users), or add Yet Another SET command
> to turn it on or off, but that would do no good for new users who would not
> understand what it is for anyway.
>
I favor a combination of [2] and [3]:  publicize the feature
but allow it to be turned off, either at compile-time or
via "set" at run-time (perhaps the latter gives most flexibility).
You could have the feature ENABLEd by default so as not to
confuse new users.  This does entail, however, warning the
"old hands" plus warning new users that when dealing with a
Kermit that does NOT support "whatamI" that they'll still
have to do a "remote set file type binary".  The key is to look at
the file status and see what it is to tell what to do.  I'm
thinking on-the-fly here.  Ah yes: even better:  tell users to
do a local SET FILE TYPE; if it doesn't work, do a REMOTE SET FILE TYPE.

Of course, when not in client/server mode (issuing commands to each Kermit),
the remote Kermit's file type still wins at present.
Given the way the Kermit protocol works, seems to me that
this must still be the case.


24-Jun-94 16:16:33-GMT,712;000000000005
Received: by watsun.cc.columbia.edu id AA27889
  (5.65c+CU/IDA-1.4.4/HLK for Frank da Cruz <[e-mail]>); Fri, 24 Jun 1994 12:16:32 -0400
Date: Fri, 24 Jun 94 12:16:27 EDT
From: Mike Freeman <[e-mail]>
To: Frank da Cruz <[e-mail]>
Subject: Re: C-Kermit "Feature?"
In-Reply-To: Your message of Fri, 24 Jun 94 11:36:22 EDT
Message-Id: <[e-mail]>

> Perhaps if I add one more bit of magic, then there will be even fewer
> surprises, namely:
>
> If you give a REMOTE SET FILE TYPE command, it should also set the local
> file type to the same thing.
>
I like it!  Great idea!  That solves the whole problem.

Mike

24-Jun-94 18:02:32-GMT,2170;000000000005
Received: by watsun.cc.columbia.edu id AA03494
  (5.65c+CU/IDA-1.4.4/HLK for fdc); Fri, 24 Jun 1994 14:02:29 -0400
Date: Fri, 24 Jun 94 14:02:28 EDT
From: Frank da Cruz <[e-mail]>
To: "John F. Chandler" <[e-mail]>
Subject: Re: Another Kermit protocol change
In-Reply-To: Your message of Fri, 1994 Jun 24 13:35 EDT
Message-Id: <[e-mail]>

> 1) For the purposes of this feature, what is a "protocol transaction"?
>    E.g., is it any sequence of packets starting with an "I" or "S"?
>    Is it a "file" transfer (successful or not)?  Do transfers include
>    short replies to server queries?
>
I'd say it's any sequence of packet exchanges that must start by setting
its packet sequence number to 0.

> 2) Should the switch caused by WHATAMI be "permanent"?  I believe it
>    should.
>
Yes.

> 3) Should the switch be made upon detecting a GET request?
>
Yes.

>    Should it be
>    made whenever a SEND operation begins in server mode?
>
I guess so, but that shouldn't matter because the old method worked here
anyway (file type in A packet).

>    Should it
>    occur whenever a WHATAMI is received?
>
I don't think so.  The S/I-packet/ACK is just an exchange of information,
not a command.  So when you get this information, just stash it away for
later use.  The main time it is useful is when you are in server mode and
you receive a GET command packet.

>    If the WHATAMI value is always used "immediately" it matters very
>    little how or when Kermit clears the saved value.
>
At the end of each transaction (B or E packet, etc) -- just in case the
client switches software on you without breaking the connection.

> 4) Is the sense of FNAMES really "inverted" as described in Draft 2?
>    The description says literal names are like binary, and converted
>    are like text.  Why, then, does binary=1 while literal=0?
>
You're right, it's inconsistent, but it's not a mistake.

> 5) Another point about the draft: the bit "names" in the figure do not
>    match those in the descriptions below, nor are the latter in the
>    same order.
>
I'll check that, thanks.

- Frank

24-Jun-94 17:42:21-GMT,3479;000000000011
Received: from cuvmb.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02620
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Fri, 24 Jun 1994 13:42:20 -0400
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1)
   with BSMTP id 5547; Fri, 24 Jun 94 13:42:34 EDT
Date: Fri, 1994 Jun 24   13:35 EDT
From: "John F. Chandler"   <[e-mail]>
To: Frank da Cruz   <[e-mail]>
Subject: Re: Another Kermit protocol change
In-Reply-To: [e-mail] message
   <[e-mail]> of Fri, 10 Jun 94 12:26:36
   EDT
Message-Id: <[e-mail]>

Frank,
   The operator was able to clear my disabled session.  Thanks.  I now
have a seemingly functional implementation of the WHATAMI feature.
However, I have some questions about the draft:

1) For the purposes of this feature, what is a "protocol transaction"?
   E.g., is it any sequence of packets starting with an "I" or "S"?
   Is it a "file" transfer (successful or not)?  Do transfers include
   short replies to server queries?

2) Should the switch caused by WHATAMI be "permanent"?  I believe it
   should.  To the user, it should appear as if a REMOTE SET FILE TYPE
   had been issued.  Also, unlike the switch made by a receiver in
   response to an "A" packet, this switch has no clearly-defined scope.
   It may need to be in effect during the transfer of more than one file
   (as in GET *), or it may not affect any files at all (if the GET
   request cannot be honored).

3) Should the switch be made upon detecting a GET request?  Should it be
   made whenever a SEND operation begins in server mode?  Should it
   occur whenever a WHATAMI is received?  If the intent is to make SET
   FILE TYPE at the client propagate to the server, then it should do so
   at every opportunity, including both the "I" packet (if any) received
   before *any* server command and the "Y" packet received after sending
   the "S" that starts *any* outward transmission.

   Other considerations: the point where the switch actually takes place
   may not matter in practice.  Unless the user issues FINISH, CONNECT,
   SHOW FILE, it makes no difference whether the server happens to be
   in binary mode at any given instant.  However, I would like to see
   a situation which is as straightforward as possible for the expert,
   not just for the tyro.  Therefore, there is a motivation for making
   the choice *standard*, whatever it happens to be.  My initial
   implementation places the switch operation in SEND (just after the
   exchange of S/Y packets), but I am inclined to favor moving it to
   the routine that interprets a received parameter packet (S/I/Y).
   If the WHATAMI value is always used "immediately" it matters very
   little how or when Kermit clears the saved value.

4) Is the sense of FNAMES really "inverted" as described in Draft 2?
   The description says literal names are like binary, and converted
   are like text.  Why, then, does binary=1 while literal=0?

5) Another point about the draft: the bit "names" in the figure do not
   match those in the descriptions below, nor are the latter in the
   same order.

Previously, I argued that bit 5 of the WHATAMI value could be reused
someday if there were a need for one more bit, but I take that back.
I was forgetting that the default has to be *ignore*.
                                       John

24-Jun-94 21:57:02-GMT,3255;000000000015
Received: from cuvmb.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA17828
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Fri, 24 Jun 1994 17:56:58 -0400
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1)
   with BSMTP id 9921; Fri, 24 Jun 94 17:57:11 EDT
Date: Fri, 1994 Jun 24   17:01 EDT
From: "John F. Chandler"   <[e-mail]>
To: Frank da Cruz   <[e-mail]>
Subject: Re: Another Kermit protocol change
In-Reply-To: [e-mail] message
   <[e-mail]> of Fri, 24 Jun 94 14:02:28
   EDT
Message-Id: <[e-mail]>

> >    Should it be
> >    made whenever a SEND operation begins in server mode?
> >
> I guess so, but that shouldn't matter because the old method worked here
> anyway (file type in A packet).

No, I meant a SEND from the server's standpoint.  In other words, the
server gets a GET command, does some validation and housekeeping, and
then begins a SEND operation.  My question was whether the switch should
be closely tied to the GET processing or not.  Consider the user command
REMOTE KERMIT REMOTE PRINT file.  Or the command REMOTE KERMIT SEND
file.  You could argue that PRINT should always be in text mode, but I
think there are exceptions.  You could argue that REM KER SEND is a
synonym for GET, but it isn't quite.  It is *not* enough to make the
switch when and only when a GET is received.  The immediate fallback
position is to do the switch as part of any SEND operation.  Or...

> >    Should it
> >    occur whenever a WHATAMI is received?
> >
> I don't think so.  The S/I-packet/ACK is just an exchange of information,
> not a command.

I'm arguing that this feature is designed to *make* this into a command
(or, rather, to make the SET FILE xxx at the client be a command to the
server).  Admittedly, the "command" doesn't take effect right away --
not until an exchange of information occurs, but the naive user is
supposedly assuming that the command is forwarded to the server.  If
you're serious about honoring that model, do it all the way.

> At the end of each transaction (B or E packet, etc) -- just in case the
> client switches software on you without breaking the connection.

In short, the saved WHATAMI value has no "archival" use -- there is
really no point in saving it at all, aside from some reluctance to
switch modes without really "needing" to.  I argue that there *is* a
need to honor the WHATAMI "command" immediately, even if the user is
not planning to do any GET requests -- just so that Kermit doesn't
become hopelessly schizophrenic.  Remember that there is no need to
send an "I" packet before the "R" packet of a GET request unless
some parameters have changed since the last exchange of info.  Even
though both CK and MSK apparently send an "I" packet unconditionally,
there is no logical reason why they should, and the draft doesn't say
they *must* in order to be WHATAMI-compliant, *and*, if the server
can react to the "Y" response to its "S" packet after beginning to
act upon a GET request, there is no justification for requiring an
unconditional "I"-before-"R".
                                       John

25-Jun-94 21:04:23-GMT,3259;000000000001
Received: by watsun.cc.columbia.edu id AA02176
  (5.65c+CU/IDA-1.4.4/HLK for fdc); Sat, 25 Jun 1994 17:04:22 -0400
Date: Sat, 25 Jun 94 17:04:21 EDT
From: Frank da Cruz <[e-mail]>
To: "John F. Chandler" <[e-mail]>
Subject: Re: Another Kermit protocol change
In-Reply-To: Your message of Fri, 1994 Jun 24 17:01 EDT
Message-Id: <[e-mail]>

> No, I meant a SEND from the server's standpoint.  In other words, the
> server gets a GET command, does some validation and housekeeping, and
> then begins a SEND operation.  My question was whether the switch should
> be closely tied to the GET processing or not.  Consider the user command
> REMOTE KERMIT REMOTE PRINT file.  Or the command REMOTE KERMIT SEND
> file.  You could argue that PRINT should always be in text mode, but I
> think there are exceptions.  You could argue that REM KER SEND is a
> synonym for GET, but it isn't quite.  It is *not* enough to make the
> switch when and only when a GET is received.  The immediate fallback
> position is to do the switch as part of any SEND operation.  Or...
>
I had not considered REMOTE KERMIT.  But K-370 is the only one that
implements it -- it's too hard for everybody else.  So yes, if you are
a server, and about to send (a) file(s), then sure, check the WHATAMI
bits from the client and make the switch at that point too.

> > >    Should it occur whenever a WHATAMI is received?
> > >
> > I don't think so.  The S/I-packet/ACK is just an exchange of information,
> > not a command.
>
> I'm arguing that this feature is designed to *make* this into a command
> (or, rather, to make the SET FILE xxx at the client be a command to the
> server).  Admittedly, the "command" doesn't take effect right away --
> not until an exchange of information occurs, but the naive user is
> supposedly assuming that the command is forwarded to the server.  If
> you're serious about honoring that model, do it all the way.
>
I suppose you might be right, but in practice I don't see where it makes
a difference.  Maybe I'm just not thinking hard enough about it.

> > At the end of each transaction (B or E packet, etc) -- just in case the
> > client switches software on you without breaking the connection.
>
> In short, the saved WHATAMI value has no "archival" use -- there is
> really no point in saving it at all, aside from some reluctance to
> switch modes without really "needing" to.  I argue that there *is* a
> need to honor the WHATAMI "command" immediately, even if the user is
> not planning to do any GET requests -- just so that Kermit doesn't
> become hopelessly schizophrenic.  Remember that there is no need to
> send an "I" packet before the "R" packet of a GET request unless
> some parameters have changed since the last exchange of info.  Even
> though both CK and MSK apparently send an "I" packet unconditionally,
> there is no logical reason why they should, and the draft doesn't say
> they *must* in order to be WHATAMI-compliant, *and*, if the server
> can react to the "Y" response to its "S" packet after beginning to
> act upon a GET request, there is no justification for requiring an
> unconditional "I"-before-"R".
>
OK, I'm coming around...

- Frank

24-Jun-94 20:33:03-GMT,792;000000000001
Received: from mail.swip.net by watsun.cc.columbia.edu with SMTP id AA12889
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Fri, 24 Jun 1994 16:32:55 -0400
Received: by mail.swip.net (8.6.8/2.01)
    id WAA22244; Fri, 24 Jun 1994 22:32:54 +0200
Received: by kullmar.se (4.1/SMI-4.1)
    id AA14972; Fri, 24 Jun 94 21:17:59 +0200
Date: Fri, 24 Jun 94 21:17:59 +0200
From: [e-mail] (Bo Kullmar)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: C-Kermit "Feature?"

> What's your opinion?

This only applays to server mode? If that is the case I think it is ok
to change it! But I think that we need some kind of message when the
clients file type is changed. It looks like that this also applys to
file name litteral/converted.

--Bo Kullmar