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 To: Mike Freeman Subject: Re: C-Kermit "Feature?" In-Reply-To: Your message of Fri, 24 Jun 94 10:51:18 EDT Cc: Bo Kullmar Message-Id: > 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 To: Frank da Cruz Subject: Re: C-Kermit "Feature?" In-Reply-To: Your message of Fri, 24 Jun 94 11:04:43 EDT Cc: freeman@watsun.cc.columbia.edu Message-Id: > 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 ); Fri, 24 Jun 1994 12:16:32 -0400 Date: Fri, 24 Jun 94 12:16:27 EDT From: Mike Freeman To: Frank da Cruz Subject: Re: C-Kermit "Feature?" In-Reply-To: Your message of Fri, 24 Jun 94 11:36:22 EDT Message-Id: > 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 To: "John F. Chandler" Subject: Re: Another Kermit protocol change In-Reply-To: Your message of Fri, 1994 Jun 24 13:35 EDT Message-Id: > 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 ); 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" To: Frank da Cruz Subject: Re: Another Kermit protocol change In-Reply-To: fdc@watsun.cc.columbia.edu message of Fri, 10 Jun 94 12:26:36 EDT Message-Id: 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 ); 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" To: Frank da Cruz Subject: Re: Another Kermit protocol change In-Reply-To: fdc@watsun.cc.columbia.edu message of Fri, 24 Jun 94 14:02:28 EDT Message-Id: > > 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 To: "John F. Chandler" Subject: Re: Another Kermit protocol change In-Reply-To: Your message of Fri, 1994 Jun 24 17:01 EDT Message-Id: > 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 ); 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: bk@kullmar.se (Bo Kullmar) Message-Id: <9406241917.AA14972@kullmar.se> To: fdc@watsun.cc.columbia.edu 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