Date: Mon, 11 Dec 89 19:15:07 EST >From: Christine M Gianone Subject: Proposal for REMOTE SET Extension to the Kermit Protocol Keywords: Kermit Protocol, REMOTE SET Command PROBLEM: Certain Kermit programs (including MS-Kermit 3.0, C-Kermit 4F) include information about whether a file is text or binary in the File Attribute packet, so the receiver can put itself into the right mode automatically. But when talking to a server there is no way for the client program, before issuing a GET command, to tell the server whether to send the file in text or binary mode. This problem extends to various other protocol and file-related parameters. NOTE: The Kermit protocol definition includes a REMOTE KERMIT command, and the associated packet format and protocol. It lets the user of the client program issue a command to the server in its own interactive-mode command language. But this is not a totally satisfactory answer because the syntax of Kermit programs can and does vary and, perhaps more to the point, some Kermit programs do not have an interactive command mode at all (Macintosh Kermit is one example). What is needed is a standard mechanism and syntax that can apply to all Kermit programs uniformly. SOLUTION: A new addition to the Kermit protocol: REMOTE SET. REMOTE SET would be a Generic Kermit Server command. A generic command looks like this: +-----+---------------------------------+ | G | x ... | +-----+---------------------------------+ Type Data where "x" is the generic command, a single letter. The letter S is not yet in use, so let's define S to mean SET. The S is followed by a single operand, which includes a single-character length field, similar to other generic command packets. The parameters which may be SET remotely are the ones having to do with file transfer and Kermit protocol in general, not system-dependent or communications-dependent parameters, since these must already have been set prior to making the initial connection, and must be set correctly in any event BEFORE you can successfully send a REMOTE SET (or any other) packet to the server. The most needed REMOTE SET command is REMOTE SET FILE TYPE {TEXT,BINARY}, but the others should be specified in the protocol too. Numeric codes are assigned to the parameters and values, so that the mechanism for conveying this information is system- and language-independent and reasonably compact. The REMOTE SET command does exactly what the corresponding SET command would do if it had been given to the remote server as an interactive command before it entered server mode. Command Code Values REMOTE SET ATTRIBUTES IN ALL 132 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN LENGTH 133 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN TYPE 134 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN DATE 135 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN CREATOR 136 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN ACCOUNT 137 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN AREA 138 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN BLOCK-SIZE 139 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN ACCESS 140 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN ENCODING 141 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN DISPOSITION 142 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN PROTECTION 143 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN GPROTECTION 144 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN SYSTEM-ID 145 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN FORMAT 146 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN SYS-INFO 147 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES IN BYTE-COUNT 148 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ALL 232 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT LENGTH 233 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT TYPE 234 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT DATE 235 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT CREATOR 236 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ACCOUNT 237 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT AREA 238 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT BLOCK-SIZE 239 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ACCESS 240 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT ENCODING 241 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT DISPOSITION 242 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT PROTECTION 243 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT GPROTECTION 244 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT SYSTEM-ID 245 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT FORMAT 246 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT SYS-INFO 247 0 = OFF, 1 = ON REMOTE SET ATTRIBUTES OUT BYTE-COUNT 248 0 = OFF, 1 = ON REMOTE SET FILE TYPE 300 0 = TEXT, 1 = BINARY REMOTE SET FILE NAMES 301 0 = CONVERTED, 1 = LITERAL REMOTE SET FILE COLLISION 302 0 = RENAME, 1 = REPLACE, 2 = BACKUP, 3 = APPEND, 4 = DISCARD, 4 = ASK REMOTE SET FILE REPLACE 303 0 = PRESERVE, 1 = DEFAULT REMOTE SET FILE INCOMPLETE 310 0 = DISCARD, 1 = KEEP REMOTE SET INCOMPLETE (same as above) *** Added Later *** REMOTE SET FILE BLOCKSIZE 311 number REMOTE SET FILE RECORD-LENGTH 312 number REMOTE SET FILE RECORD-FORMAT 313 number REMOTE SET FILE ORGANIZATION 314 number REMOTE SET FILE CARRIAGE-CONTROL 315 number *** End Added Later *** REMOTE SET BLOCK-CHECK 400 number (1, 2, 3, 4, or B) REMOTE SET RECEIVE PACKET-LENGTH 401 number (10-9024) REMOTE SET RECEIVE TIMEOUT 402 number (any, 0 = no timeout) REMOTE SET RETRY 403 number (any, 0 = no limit) REMOTE SET SERVER TIMEOUT 404 number (any, 0 = no timeout) REMOTE SET TRANSFER CHARACTER-SET 405 Character Set Designator REMOTE SET WINDOW-SLOTS 406 number (1-31) *** Added Later *** REMOTE SET TRANSFER MODE 410 0 = automatic, 1 = manual *** End Added Later *** One Kermit program should not have knowledge of another Kermit program's local character sets, therefore REMOTE SET FILE CHARACTER-SET is not included. The Transfer Character Set Designator is the one described in the "ISO/Kermit" proposal. For example "I2/100" (ISO Latin Alphabet 1), "I2/144" (ISO Latin/Cyrillic), or "I14/13" (Japanese Roman/Katakana). The command would use the name (for example REMOTE SET TRANSFER CHARACTER-SET LATIN1) and the generic server command packet would use the corresponding designator. REMOTE SET LANGUAGE is omitted for the present, but can be added later. The problem here is assigning a unique code to each of the world's languages. The numbers shown for the codes and values are expressed as character strings composed of ASCII digits, 0-9. Here are examples, showing the TYPE and DATA fields of the Kermit packet: GS#101!0 = REMOTE SET ATTRIBUTE LENGTH OFF GS#202!0 = REMOTE SET ATTRIBUTE TYPE OFF GS#300!1 = REMOTE SET FILE TYPE BINARY GS#400!2 = REMOTE SET BLOCK CHECK 2 GS#401$1000 = REMOTE SET RECEIVE PACKET-LENGTH 1000 GS#405&I2/100 = REMOTE SET TRANSFER CHARACTER-SET LATIN-1 ORGANIZATION AND EXPANSION: The codes are numeric strings, with the hundred's place assigned roughly according to "topic": 100's for Incoming Attributes, 200's for Outbound Attributes, 300's for file-related items, and 400's for packet-related items. Note that the SET ATTRIBUTE codes are equal to 100 or 200 plus the value of the corresponding attribute designator. There is plenty of room for expansion within each category, and new categories can be added as required. PROTOCOL: The person using the client Kermit program issues a REMOTE SET command for a single parameter, such as REMOTE SET FILE TYPE BINARY. The program forms the corresponding G packet and sends it to the server. The server program can respond in any of the following ways, and the client program should be prepared for each kind of response: E-packet: An Error packet. The server does not understand REMOTE SET packets, or it is not able to perform the specific SET that was requested. Therefore the client must not assume that the SET has been done, and if it is in local mode, it must give a message to the user, as described below. Y-packet: An Acknowledgement. The server accepted the command, and performed the requested SET. The data field of the Y-packet can be empty, to indicate that the requested value was accepted. Or it can contain the value which the server actually set. For example, the user types REMOTE SET RECEIVE PACKET-LENGTH 5000 but the server only supports lengths up to 1000: To server --> GS#400$5000 Y1000 <-- To client CLIENT IMPLEMENTATION: A client can include support for any number of the REMOTE SET commands, or none at all. A minimal implementation might include only REMOTE SET FILE TYPE. This would include addition of the command to the program's command tables, code to send the generic packet, and code to interpret the response and issue any appropriate messages to the user, like the contents of the error packet data field, or any altered value that the server sent back in the data field of an acknowledgement. Examples: REMOTE SET command succeeded REMOTE SET value changed to 1000 REMOTE SET command failed: SERVER IMPLEMENTATION: A server can also include support for any number of the REMOTE SET commands, or none at all. If it supports none at all, then it will automatically respond to a REMOTE SET packet with an error packet containing a message like "Unimplemented REMOTE command". If the server receives a REMOTE SET packet for a parameter it does not support the REMOTE SETting of, then it should respond with an error packet containing the message "Unknown REMOTE SET parameter". If the server gets a REMOTE SET packet for a parameter which is known to it, then it should: (a) Set the parameter to the requested value and respond with an empty Y packet, or: (b) If the requested value exceeds the server's maximum value for the parameter, set it to its own maximum value and respond with a Y packet containing the new value in its data field, as in the packet-length example above. If the server is a "permanent" Kermit server which cannot be terminated using BYE or FINISH, then when the user disengages from it using BYE, FINISH, or LOGOUT, then when the server receives a BYE, FINISH, or LOGOUT command, it should revert any parameters that were changed by REMOTE SET back to the values that were in use when server mode was entered. Thanks to Joe Doupnik and John Chandler for their assistance in the design of this protocol extension. From: Christine M Gianone Subject: Kermit Protocol Additions Keywords: Kermit Protocol This issue of the Info-Kermit Digest contains several proposals for extending the Kermit protocol in certain minor ways, all of them related. These discussions are for Kermit developers. They assume familiarity with the Kermit protocol, as described in "Kermit, A File Transfer Protocol", by Frank da Cruz, Digital Press (1987). ------------------------------ Date: Mon, 22 Jan 90 12:51:21 EST From: Christine M Gianone Subject: Additions to REMOTE SET Proposal Keywords: Kermit Protocol, REMOTE SET Command REMOTE SET FILE BLOCKSIZE 311 number REMOTE SET FILE RECORD-LENGTH 312 number REMOTE SET FILE RECORD-FORMAT 313 ??? This is just for the record, to assign these numbers to these commands for somebody who needed them. Details to be filled in later. ------------------------------ Date: Tue Jul 21 15:50:16 1998 From: fdc Subject: Additions to REMOTE SET Proposal Client/Server settings, 420 series. REMOTE SET SERVER CD-MESSAGE 420 0 = OFF, 1 = ON ------------------------------ Date: Thu Oct 14 13:46:17 1999 From: fdc Subject: REMOTE SET FILE CHARACTER-SET Here we have two choices: just pass the keywords and hope for the best (requires the client know the server's syntax) or assign codes to every possible file character-set, which would be silly since that would make us a registration authority for private charsets. Or use MIME tags, but I hate MIME. In any case, using any kind of codes means the user can't choose a set that might be supported but is not codified. So names are the lesser of two evils. REMOTE SET FILE CHARACTER-SET 320 string ------------------------------