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 mode already, you should interrupt this transfer, FINISH the server, put it in , 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)