home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / digest-1989.txt < prev    next >
Text File  |  2020-01-01  |  21KB  |  412 lines
  1. Info-Kermit Digest         Wed, 13 Dec 1989        Volume 10 : Number 5
  2.  
  3.    PROPOSALS FOR KERMIT PROTOCOL ADDITIONS -
  4.  
  5.         Proposal for Kermit SET FILE COLLISION Command
  6.         Proposal for Kermit SET ATTRIBUTE Command
  7.         Proposal for REMOTE SET Extension to the Kermit Protocol
  8.  
  9. Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU,
  10. requests for addition to or deletion from the Info-Kermit subscriber list to
  11. Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET.
  12.  
  13. Kermit files may be obtained over networks and by mail order.  On the
  14. Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
  15. SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as
  16. user anonymous (note, lower case), any password, and GET or MGET the desired
  17. files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
  18. kermit/d, and kermit/e.  You can also get Kermit files over BITNET/EARN; to
  19. get started send a message with text HELP to KERMSRV, the Kermit file
  20. server, at host CUVMA.  For detailed instructions, read the file
  21. kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request a
  22. complete list of Kermit versions and an order form from Kermit Distribution,
  23. Columbia University Center for Computing Activities, 612 West 115th Street,
  24. New York, NY 10025 USA.
  25.  
  26. ----------------------------------------------------------------------
  27.  
  28. Date: Mon, 11 Dec 89 19:15:07 EST
  29. From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
  30. Subject: Kermit Protocol Additions
  31. Keywords: Kermit Protocol
  32.  
  33. This issue of the Info-Kermit Digest contains several proposals for extending
  34. the Kermit protocol in certain minor ways, all of them related.  These
  35. discussions are for Kermit developers.  They assume familiarity with the
  36. Kermit protocol, as described in "Kermit, A File Transfer Protocol", by Frank
  37. da Cruz, Digital Press (1987).
  38.  
  39. ------------------------------
  40.  
  41. Date: Mon, 11 Dec 89 19:15:07 EST
  42. From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
  43. Subject: Proposal for Kermit SET FILE COLLISION Command
  44. Keywords: SET FILE COLLISION Command
  45.  
  46. PROBLEM:
  47.  
  48. As pointed out by Gregg Wonderly in Info-Kermit V10 #4, as well as by John
  49. Chandler and many others previously, Kermit's SET WARNING (sometimes also
  50. known as SET FILE WARNING) command is misnamed and furthermore does not allow
  51. for certain desirable kinds of behavior when a file arrives which has the same
  52. name as an existing file.
  53.  
  54. SOLUTION:
  55.  
  56. A new command to replace the old SET [FILE] WARNING command (or which can
  57. coexist with it): SET FILE COLLISION, similar to the SET FILE EXISTS command
  58. which was proposed by Gregg.  The name was changed for grammar's sake, several
  59. additional options are suggested, and their behavior described somewhat
  60. differently:
  61.  
  62. SET FILE COLLISION REPLACE: Destroy the previously existing file, replace it
  63.     with the new copy (the current behavior of SET WARNING OFF).
  64.  
  65. SET FILE COLLISION RENAME: Give the incoming file a new, unique name so that
  66.     it won't overwrite any existing files (like SET WARNING ON).  This would
  67.     be the default behavior.
  68.  
  69. SET FILE COLLISION BACKUP: Give the existing file a new, unique name, using
  70.     the same algorithm that is used on the arriving file by SET FILE COLLISION
  71.     RENAME, and then accept the incoming file under its own name.
  72.  
  73. SET FILE COLLISION DISCARD: Reject any incoming file that has the same name as
  74.     an existing file using (a) the attribute refusal mechanism ("N" in the
  75.     data field of the ACK to the Attribute packet) if the use of attribute
  76.     packets was negotiated, (b) by putting an "X" in the data field of
  77.     acknowledgements to any Data packets that arrive to request cancellation
  78.     of the file.  Always use method (b), even if also using method (a), to
  79.     in order to get on to the next file as quickly as possible.  In case the
  80.     sending Kermit does not understand either of these signals and the file
  81.     continues to arrive, do not open a new file and simply acknowledge and
  82.     discard all data packets up to the end of the file.
  83.  
  84.     As Gregg pointed out, the DISCARD option will be handy for resuming
  85.     transfer of a file group that had been interrupted.  This gives us a cheap
  86.     version of checkpointing.  A more general and protocol-driven
  87.     checkpointing mechanism will be proposed in the future.
  88.  
  89. SET FILE COLLISION APPEND: Append an arriving file to an existing file
  90.     that has the same name.  The resulting file keeps the same
  91.     system-dependent characteristics it had before, except that the date is
  92.     changed.  This options should be used with caution, since it opens the
  93.     door to creating files of mixed types (e.g. a text file appended to a
  94.     binary file, a spreadsheet appeneded to a database, etc).  Old versions
  95.     of IBM mainframe Kermit operated in this way.
  96.  
  97. SET FILE COLLISION ASK: Ask the user whether to replace, rename, discard,
  98.     or append each arriving file that has the same name as an existing file.
  99.     This option, too, should be used with caution because the file transfer
  100.     could time out if the user takes too long to answer the query.  There are
  101.     also user-interface issues: what happens to the active file transfer
  102.     display, etc.  Macintosh Kermit currently supports this in the form of
  103.     of "attended file transfer mode".
  104.  
  105. When the REPLACE and BACKUP options are in effect, a question arises
  106. (originally posed by John Chandler, author of Kermit-370).  Should the
  107. receiving Kermit create the new file using its current file settings (SET FILE
  108. TYPE, etc), or should the new file inherit the characteristics of the existing
  109. file, like protection, blocksize, record format, etc, on systems where files
  110. have such things (IBM mainframes, VAX/VMS, etc)?  There should also be a
  111. command to let the user specify this:
  112.  
  113. SET FILE REPLACE {PRESERVE, DEFAULT}
  114.  
  115. where PRESERVE would create the new file with the same characteristics as the
  116. old one, and DEFAULT would use the current file settings of the receiving
  117. Kermit program and the host operating system when creating the new file.
  118.  
  119. The setting of SET FILE COLLISION will have an effect (as FILE WARNING does
  120. now) upon the receiving Kermit's handling of the file size attribute as
  121. reported in the incoming Attribute packet.  If the REPLACE option is in force,
  122. then the existing file's size must be added to the available space before
  123. deciding whether to accept or refuse the file on the basis of space.
  124.  
  125. This new command involves no new protocol.  Its operation is strictly local
  126. to the receiving Kermit program, and gives the user added control over its
  127. behavior when receiving files.
  128.  
  129. ------------------------------
  130.  
  131. Date: Mon, 11 Dec 89 19:15:07 EST
  132. From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
  133. Subject: Proposal for Kermit SET ATTRIBUTE Command
  134. Keywords: Kermit Protocol, SET ATTRIBUTE Command
  135.  
  136. PROBLEM:
  137.  
  138. As the use of File Attribute (A) packets within Kermit programs grows more
  139. widespread, it is becoming apparent that the user needs to have more control
  140. over this feature.  Currently, most Kermit programs that support attribute
  141. packets have a command SET ATTRIBUTES {ON, OFF}, so that if one or more
  142. attributes is causing problems on the receiving computer, the sender can be
  143. commanded not to send any attributes at all and the receiver can be told to
  144. ignore all incoming attributes.
  145.  
  146. For example, suppose both the sender and receiver programs support the file
  147. creation date attribute, and the receiver sets the arriving file's date from
  148. it.  On some computers, incremental backups work according the file date and
  149. so files that are received by Kermit won't be backed up.  If the user gives
  150. the SET ATTRIBUTES OFF command, then the current date will be used when
  151. creating the incoming file, but other useful attributes like file size will be
  152. absent or ignored.  In this case, the receiving Kermit will not be able to
  153. reject an arriving file in advance if it would be too big to fit on the
  154. available storage.
  155.  
  156. You should not have to sacrifice all file attributes if only one of them is
  157. causing problems.  Furthermore, it is possible to imagine situations in which
  158. you want a certain attribute to be effective when sending a file but not when
  159. receiving, or vice-versa.  For example, suppose the date attribute works
  160. correctly when receiving a file, but when sending a file it causes the other
  161. Kermit program to crash because of a bug.  In this case, you need a way of
  162. telling your Kermit program to not to send the date attribute, but still
  163. continue to handle for incoming files.
  164.  
  165. SOLUTION:
  166.  
  167. A new command, SET ATTRIBUTE <name> {IN, OUT} {ON, OFF}.  The <name> is the
  168. name of any Kermit attribute as listed on pp.272-279 of the Kermit book, or
  169. else the word ALL to mean all attributes.  IN OFF means that the attribute
  170. should be ignored if it appears in an incoming File Attribute packet.  OUT OFF
  171. means that the named attribute should not be included in any File Attribute
  172. packets which are sent.  IN ON and OUT ON are used to enable the named
  173. incoming or outbound attributes.  If you specify ALL OFF, then the Kermit
  174. program should not set Attribute bit in the capabilities field of its
  175. Send-Init packet (equivalent to the current command SET ATTRIBUTES OFF).
  176. Examples:
  177.  
  178.   Command                      Meaning
  179.  
  180.   SET ATTRIBUTE LENGTH IN OFF  Ignore incoming length attributes
  181.   SET ATTRIBUTE DATE OUT OFF   Omit date from outbound attributes
  182.   SET ATTRIBUTE DATE OUT ON    Include date from outbound attributes
  183.   SET ATTRIBUTE ALL OUT OFF    Don't send any attributes
  184.   SET ATTRIBUTE ALL IN OFF     Ignore all incoming attributes
  185.  
  186. This new command is completely self-contained within each Kermit program.
  187. There is no additional protocol between the two Kermit programs.
  188.  
  189. Thanks to John Chandler and Joe Doupnik for advice and suggestions on these
  190. new commands.
  191.  
  192. ------------------------------
  193.  
  194. Date: Mon, 11 Dec 89 19:15:07 EST
  195. From: Christine M Gianone <cmg@watsun.cc.columbia.edu>
  196. Subject: Proposal for REMOTE SET Extension to the Kermit Protocol
  197. Keywords: Kermit Protocol, REMOTE SET Command
  198.  
  199. PROBLEM:
  200.  
  201. Certain Kermit programs (including MS-Kermit 3.0, C-Kermit 4F) include
  202. information about whether a file is text or binary in the File Attribute
  203. packet, so the receiver can put itself into the right mode automatically.  But
  204. when talking to a server there is no way for the client program, before
  205. issuing a GET command, to tell the server whether to send the file in text or
  206. binary mode.  This problem extends to various other protocol and file-related
  207. parameters.
  208.  
  209. NOTE:
  210.  
  211. The Kermit protocol definition includes a REMOTE KERMIT command, and the
  212. associated packet format and protocol.  It lets the user of the client program
  213. issue a command to the server in its own interactive-mode command language.
  214. But this is not a totally satisfactory answer because the syntax of Kermit
  215. programs can and does vary and, perhaps more to the point, some Kermit
  216. programs do not have an interactive command mode at all (Macintosh Kermit is
  217. one example).  What is needed is a standard mechanism and syntax that can
  218. apply to all Kermit programs uniformly.
  219.  
  220. SOLUTION:
  221.  
  222. A new addition to the Kermit protocol: REMOTE SET.  
  223.  
  224. REMOTE SET would be a generic Kermit server command.  A Generic command looks
  225. like this:
  226.  
  227.     +-----+---------------------------------+
  228.     |  G  | x <len1> <op1> <len2> <op2> ... |
  229.     +-----+---------------------------------+
  230.      Type   Data
  231.  
  232. where "x" is the generic command, a single letter.  The letter S is not yet in
  233. use, so let's define S to mean SET.  The S is followed by a single operand,
  234. which includes a single-character length field, similar to other generic
  235. command packets.
  236.  
  237. The parameters which may be SET remotely are the ones having to do with file
  238. transfer and Kermit protocol in general, not system-dependent or
  239. communications-dependent parameters, since these must already have been set
  240. prior to making the initial connection, and must be set correctly in any event
  241. BEFORE you can successfully send a REMOTE SET (or any other) packet to the
  242. server. 
  243.  
  244. The most needed REMOTE SET command is REMOTE SET FILE TYPE {TEXT,BINARY}, but
  245. the others should be specified in the protocol too.  Numeric codes are
  246. assigned to the parameters and values, so that the mechanism for conveying
  247. this information is system- and language-independent and reasonably compact.
  248. The REMOTE SET command does exactly what the corresponding SET command would
  249. do if it had been given to the remote server as an interactive command before
  250. it entered server mode.
  251.   
  252.   Command                                Code   Values
  253.  
  254.   REMOTE SET ATTRIBUTES IN ALL            132   0 = OFF, 1 = ON
  255.   REMOTE SET ATTRIBUTES IN LENGTH         133   0 = OFF, 1 = ON
  256.   REMOTE SET ATTRIBUTES IN TYPE           134   0 = OFF, 1 = ON
  257.   REMOTE SET ATTRIBUTES IN DATE           135   0 = OFF, 1 = ON
  258.   REMOTE SET ATTRIBUTES IN CREATOR        136   0 = OFF, 1 = ON
  259.   REMOTE SET ATTRIBUTES IN ACCOUNT        137   0 = OFF, 1 = ON
  260.   REMOTE SET ATTRIBUTES IN AREA           138   0 = OFF, 1 = ON
  261.   REMOTE SET ATTRIBUTES IN BLOCK-SIZE     139   0 = OFF, 1 = ON
  262.   REMOTE SET ATTRIBUTES IN ACCESS         140   0 = OFF, 1 = ON
  263.   REMOTE SET ATTRIBUTES IN ENCODING       141   0 = OFF, 1 = ON
  264.   REMOTE SET ATTRIBUTES IN DISPOSITION    142   0 = OFF, 1 = ON
  265.   REMOTE SET ATTRIBUTES IN PROTECTION     143   0 = OFF, 1 = ON
  266.   REMOTE SET ATTRIBUTES IN GPROTECTION    144   0 = OFF, 1 = ON
  267.   REMOTE SET ATTRIBUTES IN SYSTEM-ID      145   0 = OFF, 1 = ON
  268.   REMOTE SET ATTRIBUTES IN FORMAT         146   0 = OFF, 1 = ON
  269.   REMOTE SET ATTRIBUTES IN SYS-INFO       147   0 = OFF, 1 = ON
  270.   REMOTE SET ATTRIBUTES IN BYTE-COUNT     148   0 = OFF, 1 = ON
  271.  
  272.   REMOTE SET ATTRIBUTES OUT ALL           232   0 = OFF, 1 = ON
  273.   REMOTE SET ATTRIBUTES OUT LENGTH        233   0 = OFF, 1 = ON
  274.   REMOTE SET ATTRIBUTES OUT TYPE          234   0 = OFF, 1 = ON
  275.   REMOTE SET ATTRIBUTES OUT DATE          235   0 = OFF, 1 = ON
  276.   REMOTE SET ATTRIBUTES OUT CREATOR       236   0 = OFF, 1 = ON
  277.   REMOTE SET ATTRIBUTES OUT ACCOUNT       237   0 = OFF, 1 = ON
  278.   REMOTE SET ATTRIBUTES OUT AREA          238   0 = OFF, 1 = ON
  279.   REMOTE SET ATTRIBUTES OUT BLOCK-SIZE    239   0 = OFF, 1 = ON
  280.   REMOTE SET ATTRIBUTES OUT ACCESS        240   0 = OFF, 1 = ON
  281.   REMOTE SET ATTRIBUTES OUT ENCODING      241   0 = OFF, 1 = ON
  282.   REMOTE SET ATTRIBUTES OUT DISPOSITION   242   0 = OFF, 1 = ON
  283.   REMOTE SET ATTRIBUTES OUT PROTECTION    243   0 = OFF, 1 = ON
  284.   REMOTE SET ATTRIBUTES OUT GPROTECTION   244   0 = OFF, 1 = ON
  285.   REMOTE SET ATTRIBUTES OUT SYSTEM-ID     245   0 = OFF, 1 = ON
  286.   REMOTE SET ATTRIBUTES OUT FORMAT        246   0 = OFF, 1 = ON
  287.   REMOTE SET ATTRIBUTES OUT SYS-INFO      247   0 = OFF, 1 = ON
  288.   REMOTE SET ATTRIBUTES OUT BYTE-COUNT    248   0 = OFF, 1 = ON
  289.  
  290.   REMOTE SET FILE TYPE                    300   0 = TEXT, 1 = BINARY
  291.   REMOTE SET FILE NAMES                   301   0 = CONVERTED, 1 = LITERAL
  292.   REMOTE SET FILE COLLISION               302   0 = RENAME,  1 = REPLACE,
  293.                                                 2 = BACKUP,  3 = APPEND,
  294.                                                 4 = DISCARD, 4 = ASK
  295.   REMOTE SET FILE REPLACE                 303   0 = PRESERVE, 1 = DEFAULT
  296.   REMOTE SET FILE INCOMPLETE              310   0 = DISCARD, 1 = KEEP
  297.   REMOTE SET INCOMPLETE (same as above)
  298.  
  299.   REMOTE SET BLOCK-CHECK                  400   number (1, 2, or 3)
  300.   REMOTE SET RECEIVE PACKET-LENGTH        401   number (10-9024)
  301.   REMOTE SET RECEIVE TIMEOUT              402   number (any, 0 = no timeout)
  302.   REMOTE SET RETRY                        403   number (any, 0 = no limit)
  303.   REMOTE SET SERVER TIMEOUT               404   number (any, 0 = no timeout)
  304.   REMOTE SET TRANSFER CHARACTER-SET       405   Character Set Designator
  305.   REMOTE SET WINDOW-SLOTS                 406   number (1-31)
  306.  
  307. One Kermit program should not have knowledge of another Kermit program's local
  308. character sets, therefore REMOTE SET FILE CHARACTER-SET is not included.  The
  309. Transfer Character Set Designator is the one described in the "ISO/Kermit"
  310. proposal.  For example "I2/100" (ISO Latin Alphabet 1), "I2/144" (ISO
  311. Latin/Cyrillic), or "I14/13" (Japanese Roman/Katakana).  The command would
  312. use the name (for example REMOTE SET TRANSFER CHARACTER-SET LATIN1) and the
  313. generic server command packet would use the corresponding designator.
  314.  
  315. REMOTE SET LANGUAGE is omitted for the present, but can be added later.  The
  316. problem here is assigning a unique code to each of the world's languages.
  317.  
  318. The numbers shown for the codes and values are expressed as character
  319. strings composed of ASCII digits, 0-9.  Here are examples, showing the TYPE
  320. and DATA fields of the Kermit packet:
  321.  
  322.   GS#101!0      = REMOTE SET ATTRIBUTE LENGTH OFF
  323.   GS#202!0      = REMOTE SET ATTRIBUTE TYPE OFF
  324.   GS#300!1      = REMOTE SET FILE TYPE BINARY
  325.   GS#400!2      = REMOTE SET BLOCK CHECK 2
  326.   GS#401$1000   = REMOTE SET RECEIVE PACKET-LENGTH 1000
  327.   GS#405&I2/100 = REMOTE SET TRANSFER CHARACTER-SET LATIN-1
  328.  
  329. ORGANIZATION AND EXPANSION:
  330.  
  331. The codes are numeric strings, with the hundred's place assigned roughly
  332. according to "topic": 100's for Incoming Attributes, 200's for Outbound
  333. Attributes, 300's for file-related items, and 400's for packet-related items.
  334. Note that the SET ATTRIBUTE codes are equal to 100 or 200 plus the value of
  335. the corresponding attribute designator.  There is plenty of room for expansion
  336. within each category, and new categories can be added as required.
  337.  
  338. PROTOCOL:
  339.  
  340. The person using the client Kermit program issues a REMOTE SET command for
  341. a single parameter, such as REMOTE SET FILE TYPE BINARY.  The program forms
  342. the corresponding G packet and sends it to the server.
  343.  
  344. The server program can respond in any of the following ways, and the client
  345. program should be prepared for each kind of response:
  346.  
  347.   E-packet:  An Error packet.  The server does not understand REMOTE SET
  348.              packets, or it is not able to perform the specific SET that was
  349.              requested.  Therefore the client must not assume that the SET has
  350.              been done, and if it is in local mode, it must give a message to
  351.              the user, as described below.
  352.  
  353.   Y-packet:  An Acknowledgement.  The server accepted the command, and
  354.              performed the requested SET.  The data field of the Y-packet can
  355.              be empty, to indicate that the requested value was accepted.  Or
  356.              it can contain the value which the server actually set.  For
  357.              example, the user types REMOTE SET RECEIVE PACKET-LENGTH 5000 but
  358.              the server only supports lengths up to 1000:
  359.  
  360.                 To server -->  GS#400$5000
  361.                                Y1000        <-- To client
  362.  
  363. CLIENT IMPLEMENTATION:
  364.  
  365. A client can include support for any number of the REMOTE SET commands, or
  366. none at all.  A minimal implementation might include only REMOTE SET FILE
  367. TYPE.  This would include addition of the command to the program's command
  368. tables, code to send the generic packet, and code to interpret the response
  369. and issue any appropriate messages to the user, like the contents of the
  370. error packet data field, or any altered value that the server sent back in
  371. the data field of an acknowledgement.  Examples:
  372.         
  373.     REMOTE SET command succeeded
  374.     REMOTE SET value changed to 1000
  375.     REMOTE SET command failed: <reason from data field of E-packet>    
  376.  
  377. SERVER IMPLEMENTATION:
  378.  
  379. A server can also include support for any number of the REMOTE SET commands,
  380. or none at all.  If it supports none at all, then it will automatically
  381. respond to a REMOTE SET packet with an error packet containing a message
  382. "Unimplemented REMOTE command".
  383.  
  384. If the server receives a REMOTE SET packet for a parameter it does not support
  385. the REMOTE SETting of, then it should respond with an error packet containing
  386. the message "Unknown REMOTE SET parameter".
  387.  
  388. If the server gets a REMOTE SET packet for a parameter which is known to it,
  389. then it should:
  390.  
  391. (a) Set the parameter to the requested value and respond with an empty Y
  392.     packet, or:
  393.  
  394. (b) If the requested value exceeds the server's maximum value for the
  395.     parameter, set it to its own maximum value and respond with a Y packet
  396.     containing the new value in its data field, as in the packet-length
  397.     example above.
  398.  
  399. If the server is a "permanent" Kermit server which cannot be terminated using
  400. BYE or FINISH, then when the user disengages from it using BYE, FINISH, or
  401. LOGOUT, then when the server receives a BYE, FINISH, or LOGOUT command, it
  402. should revert any parameters that were changed by REMOTE SET back to the
  403. values that were in use when server mode was entered.
  404.  
  405. Thanks to Joe Doupnik and John Chandler for assistance with the design of this
  406. protocol extension.
  407.  
  408. ------------------------------
  409.  
  410. End of Info-Kermit Digest
  411. *************************
  412.