1-Jun-96 1:44:26-GMT,3545;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id VAA14253; Fri, 31 May 1996 21:44:25 -0400 (EDT) Date: Fri, 31 May 96 21:44:25 EDT From: Frank da Cruz To: Christine M Gianone , Jeffrey Altman , Joe Doupnik , John Chandler , Terry Kennedy Subject: A new field for Kermit init string Message-ID: Dear Committee (listed in alphabetical order :-) -- "A small change for Kermit, a giant leap for userkind" ??? When I originally designed Attribute packets, my idea was that they could somehow be bundled with files themselves for purposes of archiving when transferring to an unlike system. Thus the "system of origin" field went into the A packet so a file could be tagged with it if desired, and then float around to various other kinds of systems, finally find its way back the same type of system it started from, and then the attributes could be used to put it back together. Well, that one never panned out, and I keep wishing I had the system-type attribute in the init string (S/I packet and Ack thereto), because then I'd know what kind of OS I was getting a file from (or sending it *to*) BEFORE I received a filename, rather than after, when it's too late. So in the interest of being nice to users, even at the expense of violating all that is holy about "common intermediate representations" in protocols, I would like to add this bit to the init string. That way, for example, if I should get a file whose name is full of backslashes, and it is from DOS, and I am on UNIX, I can turn the backslashes around. And vice versa. And many other things. For example, I could even skip record format conversion while still allowing character-set translation, thus making the code go faster. It's information only. The receiver of the information can do whatever s/he wants with it, including ignore it. Obviously all correctly coded present-day Kermits will indeed ignore it, but incorrectly coded ones (like Mustang BBS) will no doubt core dump or something -- good :-) Also we have a precedent -- ftp has been doing this for 30 years :-) That's how two UNIXes know when they hook up to transfer in binary mode. We could do that too if we wanted. Advantage: no more accidental trashing of binary files in UNIX-to-UNIX (or any other pair that makes sense) transfers. Disadvantage: character sets won't get translated, but *usually* that's not an issue between like systems -- at least not as great an issue as the ruining of binary files (which nowadays might well be, as many people loudly claim, the bulk of all file transfers -- GIF, ZIP, Z, etc). Perhaps best of all, VMS-to-VMS and OS/2-to-OS/2 transfers could go into labeled mode (preservation of all RMS or Extended attributes and bizarre record formats) automatically. Clearly the implementation would want commands to turn this on and off; SET TRANSFER MODE { AUTOMATIC, MANUAL } SET FILE NAMES { CONVERTED, LITERAL, AUTOMATIC } So, wherever the init string ends these days -- right after the WHATAMI field, no? -- which is at CAPAS+8 -- let's add a length-encoded field at CAPAS+9, which is exactly the same as the length-encoded System ID attribute from the A packet. OK? (This one is easy -- I'm still putting off tackling the system-independent representation of file systems...) - Frank 1-Jun-96 2:25:19-GMT,750;000000000001 Received: from GRUMPY.USU.EDU (grumpy.usu.edu [129.123.1.86]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id WAA17734 for ; Fri, 31 May 1996 22:25:18 -0400 (EDT) Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556) id <01I5D9WBM1808ZYJB9@cc.usu.edu> for fdc@watsun.cc.columbia.edu; Fri, 31 May 1996 20:25:15 -0600 (MDT) Date: Fri, 31 May 1996 20:25:15 -0600 (MDT) From: Joe Doupnik Subject: Re: A new field for Kermit init string To: fdc@watsun.cc.columbia.edu Message-id: <01I5D9WBRLTU8ZYJB9@cc.usu.edu> X-VMS-To: IN%"fdc@watsun.cc.columbia.edu" X-VMS-Cc: JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Frank, Ok. Neat stuff. Joe D. 1-Jun-96 2:59:53-GMT,2438;000000000005 Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id WAA20229; Fri, 31 May 1996 22:59:52 -0400 (EDT) Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1) with BSMTP id 6299; Fri, 31 May 96 22:59:20 EDT Date: Fri, 1996 May 31 22:22 EDT From: (John F. Chandler)JCHBN@CUVMB.CC.COLUMBIA.EDU To: (Frank da Cruz)fdc@watsun.CC.COLUMBIA.EDU, (Christine M Gianone)cmg@watsun.CC.COLUMBIA.EDU, (Jeffrey Altman)jaltman@watsun.CC.COLUMBIA.EDU, (Joe Doupnik)JRD@cc.usu.edu, (Terry Kennedy)TERRY@SPCVXA.SPC.EDU Subject: Re: A new field for Kermit init string In-reply-to: fdc@watsun.cc.columbia.edu message of Fri, 31 May 96 21:44:25 EDT Message-id: Frank and others, > "A small change for Kermit, a giant leap for userkind" ??? Should be a small *hop*, shouldn't it?? > I keep wishing I had the system-type > attribute in the init string (S/I packet and Ack thereto), I guess it can't hurt, in itself, but there is a strangeness here -- this would be the first time that a *receiving* Kermit revealed its type. It opens all kinds of possibilities for doing special processing according to the target system -- but Kermit practice has always been geared toward sending things generically and doing the special treatment at the receiving end. > That's how two UNIXes know when they hook up to transfer in binary mode. > We could do that too if we wanted. Advantage: no more accidental trashing of > binary files in UNIX-to-UNIX (or any other pair that makes sense) transfers. On the other hand, we have worked very hard to implement proper character translations in Kermit. International transfers may need to stay "manual". I note that IBM mainframes nearly always are talking to UNlike systems. The major exception is when the mainframe is "talking to itself" as in the case of replaying a "canned" Kermit transfer to install a file. Basically, I don't see much mileage for K370 here. Oh, well... > let's add a length-encoded field at CAPAS+9, > which is exactly the same as the length-encoded System ID attribute from the A > packet. OK? Do we include the "." that says "this is the System ID attribute"? Or do we start with the length byte? John 1-Jun-96 3:34:27-GMT,3370;000000000005 Received: from barney.usu.edu (barney.usu.edu [129.123.1.89]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id XAA23251; Fri, 31 May 1996 23:34:26 -0400 (EDT) Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556) id <01I5DBYCJ84W8ZYOUN@cc.usu.edu>; Fri, 31 May 1996 21:34:17 -0600 (MDT) Date: Fri, 31 May 1996 21:34:17 -0600 (MDT) From: Joe Doupnik Subject: Re: A new field for Kermit init string To: JCHBN@CUVMB.CC.COLUMBIA.EDU Cc: FDC@WATSUN.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, CMG@WATSUN.CC.COLUMBIA.EDU Message-id: <01I5DBYCJAYQ8ZYOUN@cc.usu.edu> X-VMS-To: IN%"JCHBN@CUVMB.CC.COLUMBIA.EDU" X-VMS-Cc: FDC@WATSUN.CC.COLUMBIA.EDU,TERRY@SPCVXA.SPC.EDU,CMG@WATSUN.CC.COLUMBIA.EDU,JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT John, I interpreted the new material to be , such as "U8 where 32+2 = " and U8 is portable MSDOS. No dot attribute introducer. I just added this to the spar/rpar S/I parsing routines in MSK. The controlling user level commands and attendent "if kith&kin then binary on them" code have not been added yet. Yes, there is a violation of the general rules if automatic mode selection occurs via this mechanism since it zaps the character set finesse we struggled with for years. So the default mode could be to not do this, as the group wishes. Joe D. ------- Attachment: MSK client to CK server, sending file ker.lnk, receiving it, deleting the debris on the Unix side, bye. Recorded on the MSK client: vvv---------- these three bytes added for MS-DOS Spack: ^A8 S~( @-#Y3~^$5% ___D"U87^M Rpack: ^A5 Y~* @-#Y3~^$5$0___E^^M Spack: ^A,!FKER.LNK-'9^M Rpack: ^A,!Yker.lnk+QK^M vvv------ regular place for sysid Spack: ^AN"A1#233!!1#119960407 20:28:32."U8"#AMJ*!A@ '_Q^M Rpack: ^A%"Y.5!^M Spack: ^A #D"X!msscmd+msscom+mssfil+mssker+mssrcv+m~#scp+m~#sen+m~#ser +#M#Jm~#set+m~#sho+msster+msgibm+msuibm+msxibm+msyibm+mszibm+#M#Jmsntn i+msnpdi+msntnd+msntcp+msnsed+msndns+msnarp+msnbtp+#M#Jmsnicm+msnpkt+m snlib+msnut1#M#JKermit/nodefaultlib/exepack;#M#J-_F^M Spack: ^A%$Z(,*^M Rpack: ^A%#Y/R9^M Rpack: ^A%$Y+&1^M Spack: ^A%%B 8;^M Rpack: ^A%%Y*A)^M Spack: ^A8 I~( @-#Y3~^!5% ___D"U8*^M Rpack: ^A5 Y~* @-#Y3~^$5$0___E^^M Spack: ^A* Rker.lnk2^M Rpack: ^A5 S~* @-#Y3~^$5$0___EX^M Spack: ^A8 Y~( @-#Y3~^$5% ___D"U8=^M Rpack: ^A,!FKER.LNK-'9^M Spack: ^A/!Y g:KER.LNK((>^M Rpack: ^AN"A."U1"#AMJ*!A#119960407 20:28:32!!11#228@ *UH^M Spack: ^A%"Y.5!^M Rpack: ^A #D"X!msscmd+msscom+mssfil+mssker+mssrcv+m~#scp+m~#sen+m~#ser +#M#Jm~#set+m~#sho+msster+msgibm+msuibm+msxibm+msyibm+mszibm+#M#Jmsntn i+msnpdi+msntnd+msntcp+msnsed+msndns+msnarp+msnbtp+#M#Jmsnicm+msnpkt+m snlib+msnut1#M#JKermit/nodefaultlib/exepack;#M#J-_F^M Spack: ^A%#Y/R9^M Rpack: ^A%$Z(,*^M Spack: ^A%$Y+&1^M Rpack: ^A%%B 8;^M Spack: ^A%%Y*A)^M Spack: ^A8 I~( @-#Y3~^!5% ___D"U8*^M Rpack: ^A5 Y~* @-#Y3~^$5$0___E^^M Spack: ^A, GE'ker.lnkV^M Rpack: ^A5 S~* @-#Y3~^$5$0___EX^M Spack: ^A8 Y~( @-#Y3~^$5% ___D"U8=^M Rpack: ^A+!Xdelete$1-^M Spack: ^A)!Y CON(]B^M Rpack: ^A3"A."U1"#AMJ*!A@ "P6^M Spack: ^A%"Y.5!^M Rpack: ^A #D!"-#M#JDeleting ker.lnk#M#J#M#J~$ deleted: ker.lnk#M#J#M#J 1 file deleted, 228 bytes freed#M#J#M#J-:B^M Spack: ^A%#Y/R9^M Rpack: ^A%$Z(,*^M Spack: ^A%$Y+&1^M Rpack: ^A%%B 8;^M Spack: ^A%%Y*A)^M Spack: ^A$ GL:^M Rpack: ^A# Y>^M 1-Jun-96 17:30:18-GMT,1799;000000000001 Received: from SLEEPY.USU.EDU (sleepy.usu.edu [129.123.1.85]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA14269; Sat, 1 Jun 1996 13:30:17 -0400 (EDT) Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556) id <01I5E55Z56CW8ZYOH5@cc.usu.edu>; Sat, 01 Jun 1996 11:30:07 -0600 (MDT) Date: Sat, 01 Jun 1996 11:30:07 -0600 (MDT) From: Joe Doupnik Subject: Re: auto file transfer mode To: FDC@WATSUN.CC.COLUMBIA.EDU Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, CMG@WATSUN.CC.COLUMBIA.EDU Message-id: <01I5E55ZCX5E8ZYOH5@cc.usu.edu> X-VMS-To: FDC@WATSUN.CC.COLUMBIA.EDU X-VMS-Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU,TERRY@SPCVXA.SPC.EDU,CMG@WATSUN.CC.COLUMBIA.EDU,JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Frank and the group, I tacked in the code to try the proposed automatic file transfer mode sensing scheme. It goes like this in MSK/today's-edition: I/S packets have the system ident attached as per spec. That's "U8 where " is byte count of two, U is portable o/s, 8 is MS-DOS. New command SET TRANSFER MODE {Automatic, Manual} has been added, with the default being manual (as we were before). SHOW PROTOCOL reveals the current setting. If automatic mode is selected then the response to I/S packets is checked first for the sysid matching the MSK side. If it matches then automatic mode forces a "set file type binary", else manual mode skips this set file type binary operation. The consequence is "automatic" and between like systems forces SET FILE TYPE BINARY and it sticks that way. There is the carry over of this setting from network session to network session, alas. I'll put a copy of MSK v3.15 1 June 96 in my watsun account as binary file msk315.exe. Joe D. From fdc Sat Jun 1 20:39:41 1996 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id UAA00949; Sat, 1 Jun 1996 20:39:23 -0400 (EDT) Date: Sat, 1 Jun 96 20:39:22 EDT From: Frank da Cruz To: Joe Doupnik Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, CMG@WATSUN.CC.COLUMBIA.EDU, Jeffrey Altman Subject: Re: auto file transfer mode In-Reply-To: Your message of Sat, 01 Jun 1996 11:30:07 -0600 (MDT) Message-ID: > I tacked in the code to try the proposed automatic file transfer > mode sensing scheme. It goes like this in MSK/today's-edition: > I/S packets have the system ident attached as per spec. That's > "U8 where " is byte count of two, U is portable o/s, 8 is MS-DOS. > Works just right. I did the same in C-Kermit, but with many and varied system ID codes for UNIX, OS/2, OS-9, VMS, AOS/VS, VOS, etc. The associated name (e.g. "UNIX" for U1, "MS-DOS" for U8, etc) goes into the transaction log, and also gets displayed on the file transfer screen. > New command SET TRANSFER MODE {Automatic, Manual} has been added, > with the default being manual (as we were before). SHOW PROTOCOL reveals > the current setting. > Here too, except default is automatic. Probably should be in MSK too, since MSK is not going to be used that often for transferring files with other MSKs. > If automatic mode is selected then the response to I/S packets > is checked first for the sysid matching the MSK side. If it matches then > automatic mode forces a "set file type binary", else manual mode skips > this set file type binary operation. > The criterion for MSK switching into binary mode (and literal filenames) should be not just that the other end is U8, but also UO (OS/2), UN (NT), or K2 (GEMDOS) -- they all have the same file structure and naming (give or take length of filenames). Also, it should be stated that this business takes precedence over the WHATAMI stuff from two years ago, since it is more likely to compensate for a mis-set FILE TYPE. > The consequence is "automatic" and between like systems forces > SET FILE TYPE BINARY and it sticks that way. There is the carry over of this > setting from network session to network session, alas. > So as suggested earlier, maybe binary/text mode should be sticky per network session? (No worries about this in C-Kermit -- only one session.) > I'll put a copy of MSK v3.15 1 June 96 in my watsun account as > binary file msk315.exe. > Using it now, works great, but still has those three key map oddities: Is Should be Backspace Undefined \127 Ctrl-SP \0 \Knull Ctrl-@ \0 \Knull Also, I realized that the proposed SET FILE NAMES { CONVERTED, LITERAL, AUTOMATIC } was useless -- don't need it. Instead, it's just CONVERTED and LITERAL (as before), but bundled in with the transfer-mode switching, if any. (Remember, this is still separate from { SEND, RECEIVE } PATHNAMES.) So far so good. Works great UNIX-to-UNIX, UNIX/MS-DOS, UNIX/VMS, etc. For VMS/VMS and OS2/OS2 we use labeled mode, but I haven't tested this yet. Kermit-370 probably just needs to send the system ID and nothing more. Then at least the other Kermits can note on their display screens and/or transaction logs that the file came from MVS or VM/CMS or CICS, etc. Having no shame, I roughed in a quick "database" for C-Kermit regarding other system types in case we want to do something special with them: /* Kermit system IDs and associated properties... */ struct sysdata { char *sid_code; /* Kermit system ID code */ char *sid_name; /* Descriptive name */ short sid_unixlike; /* Flag: Tree-structured directory with separators */ char sid_dirsep; /* Directory separator character if unixlike */ short sid_dev; /* Filespec can start with dev: */ short sid_case; /* Bit mapped: 1 = case matters, 2 = case preserved */ short sid_recfm; /* Text record separator */ /* Recfm: 0 = unknown or nonstream 1 = cr 2 = lf 3 = crlf */ }; Haven't used any of this yet, but maybe tomorrow I'll add a few lines of code for \ / conversion, dev: stripping, etc, and report back. Meanwhile, here's a rough first cut at a table for some system types, probably most of them wrong in the details... struct sysdata sysidlist[] = { /* Add others as needed... */ "A1", "Apple II", 0, NUL, 0, 0, 3, /* fix this */ "A3", "Macintosh", 1, ':', 0, 2, 1, "D7", "VMS", 0, ']', 1, 0, 0, "DA", "RSTS/E", 0, ']', 1, 0, 3, /* (i think...) */ "DB", "RT11", 0, NUL, 1, 0, 3, /* (maybe...) */ "F3", "AOS/VS", 1, ':', 0, 0, 2, "I1", "VM/CMS", 0, NUL, 0, 0, 0, "I2", "MVS/TSO", 0, NUL, 0, 0, 0, "I4", "MUSIC", 0, NUL, 0, 0, 0, "I7", "CICS", 0, NUL, 0, 0, 0, "I9", "MVS/ROSCOE", 0, NUL, 0, 0, 0, "K2", "Atari ST", 1, '\\', 1, 0, 3, "L3", "Amiga", 1, '/', 1, 0, 2, "MV", "Stratus VOS", 1, '>', 0, 1, 0, "N3", "Apollo Aegis", 1, '/', 0, 3, 2, "U1", "UNIX", 1, '/', 0, 3, 2, "U8", "MS-DOS", 1, '\\', 1, 0, 3, "UD", "OS-9", 1, '/', 0, 3, 2, "UN", "Windows-32", 1, '\\', 1, 2, 3, "UO", "OS/2", 1, '\\', 1, 2, 3 }; I think the discerning user will love this feature; the regular user will never know about it because it will just do what was always supposed to happen anyway... - Frank From fdc Sun Jun 2 10:02:37 1996 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id KAA11823; Sun, 2 Jun 1996 10:02:34 -0400 (EDT) Date: Sun, 2 Jun 96 10:02:34 EDT From: Frank da Cruz To: Joe Doupnik Cc: jaltman@columbia.edu, JCHBN@CUVMB.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, CMG@WATSUN.CC.COLUMBIA.EDU Subject: Re: auto file transfer mode In-Reply-To: Your message of Sat, 01 Jun 1996 20:05:48 -0600 (MDT) Message-ID: Clarifications -- my little table of system properties has nothing to do with Kermit protocol or negotiations, and I certainly don't want to get (very much) into the n x n problems. Didn't explain things verbosely enough yesterday, which is abnormal, I know :-) The "unixlike" flag means that pathnames are a sequence of directory names, separated by a single character like / or \ or :, that can be easily replaced by another single char if two systems are "unixlike" but use different separators. If "dev" is set, then the name can start with a device name and colon (as in, not only DOS and VMS, but AmigaDOS, which has an otherwise "unixlike" file system). Thus VMS (RSTS, etc) can't be unixlike because it uses [...] pairs. But that is not to say that a (groan) "knowledge base" can't be constructed to handle this format. The database only says what it is, not what we'll do with it. But hard cases like VMS can't be table-driven. The "recfm" byte is similar. It applies to stream-format file systems in which text records end in a particular character or sequence, such as CR, LF, or CRLF. If they don't, this is 0, meaning "I don't understand this file format". Jeff said: > I was just thinking that OS type might not be enough information. In > fact, the reality is that we really don't care much about the OS, but > instead we care about the file system type. > > On Windows-32 or OS/2 or AIX for that matter, it probably makes a > difference whether we are transfering from/to a particular file system. > OS/2 uses FAT 8.3 notation when receiving on FAT, or Novell mounted > drives; HPFS long file names on HPFS; and NFS names on a NFS mount. > I'm not worried about this. We already handle filename conversion. If a long-named file whose name contains seventeen dots plus imbedded spaces and full-motion video Java objects comes in to an 8.3 FAT system, we'll shrink the name to fit -- we always have. But the text format (lines with CRLF) is the same in all cases. (If new plain-text formats appear, we'll have to do something about it.) If a foreign file system is mounted on my computer, it is mapped into my local naming and formatting conventions, right? If not, I'm not gonna worry about it now. Joe said: > > I didn't expect to see the NxN problem arise here and I wish it > would quietly go away. Honestly I have no faith at all in computer > programs figuring out the proper file transfer mode by themselves. > I've always felt the same way, but then again, I'm the guy who gets 500 complaints a day about files that were garbaged because they were transferred in the wrong mode (not to mention the taunts from Chuck about Kermit's "default file corruption mode"), so if there is something we can do about that is relatively easy to program, easy to explain, and "failsafe", it's worth it, no? The lesson of the 90s is that users don't want to have to know anything -- not even anything as simple as "set file type binary". They demand that software "does the right thing" because "computers are supposed to be smart". > And, to take but one common example here, no one wants to transfer a text > file in binary mode between two VMS VAXen. That means even file system names > per se are insufficient to define matters. > That's what is so terrific about labeled transfer mode. VMS-to-VMS transfers will go in labeled mode, and therefore *all* files, even ISAM ones, will be transferred correctly. Anyway, let me try a few proof-in-pudding experiments today and see how this feels... If it can't be kept simple and explainable and foolproof, it might not be worth doing. But so far it's working out pretty well. Maybe we don't need the table or one-sided conversions at all. - Frank 2-Jun-96 15:16:31-GMT,1403;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id LAA19115; Sun, 2 Jun 1996 11:16:18 -0400 (EDT) Date: Sun, 2 Jun 96 11:16:18 EDT From: Frank da Cruz To: Joe Doupnik Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, CMG@WATSUN.CC.COLUMBIA.EDU Subject: Re: auto file transfer mode In-Reply-To: Your message of Sat, 01 Jun 1996 11:30:07 -0600 (MDT) Message-ID: Well now that I've had some coffee and time for a little more testing, I'm satisfied with it as it is. Forget the table and the n x n stuff, at least for now. Just automatically switching into binary (or labeled) and literal-filename mode based on system ID is quite enough for one weekend. It feels good, it feels right. VMS-to-VMS transfers automatically pop into labeled mode, as they should, and the results (based on inspection plus DIRECTORY/FULL, etc) are perfect, so I assume the same will be true of OS/2-to-OS/2 transfers. And of course (back to VMS) we don't worry that the Kermit on the other end is really Kermit-32, because it will never send its system ID in the init string. (Putting the program name and version number in the init string would be going too far...) The other stuff is, of course, a can of worms and best avoided. So now on to the next thing, whatever it is... - Frank 2-Jun-96 0:51:37-GMT,1730;000000000001 Received: from spcvxa.spc.edu (spcvxa.spc.edu [192.107.46.27]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id UAA01961 for ; Sat, 1 Jun 1996 20:51:36 -0400 (EDT) Received: from spcvxa.spc.edu by spcvxa.spc.edu (PMDF V5.0-7 #14038) id <01I5EOWYKMNK8WVZ9U@spcvxa.spc.edu> for fdc@WATSUN.CC.COLUMBIA.EDU; Sat, 01 Jun 1996 20:51:30 -0400 (EDT) Date: Sat, 01 Jun 1996 20:51:30 -0400 (EDT) From: "Terry Kennedy, Operations Mgr" Subject: Re: auto file transfer mode To: fdc@WATSUN.CC.COLUMBIA.EDU Message-id: <01I5EOWYLP8I8WVZ9U@spcvxa.spc.edu> Organization: St. Peter's College, US X-VMS-To: IN%"fdc@WATSUN.CC.COLUMBIA.EDU" X-VMS-Cc: TERRY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT [Just to you, I'm too tired to type in the whole CC list to VMS mail 8-] > struct sysdata sysidlist[] = { /* Add others as needed... */ > "D7", "VMS", 0, ']', 1, 0, 0, Note that on VMS a complete filespec like: $1$DIA0:[SYS0.][SYSCOMMON.SYSEXE]FOO.BAR;6 is valid, so the dirsep has to be the most right-hand occurrance of the dirsep character. > "DA", "RSTS/E", 0, ']', 1, 0, 3, /* (i think...) */ Yes. Note that both RSTS/E and VMS support RMS files. RSTS/E also supports a native stream-ish format. I don't know that the refm byte is going to buy us much of anything, ex- cept in the cases of sender and recipient both being the same non-zero value, in which case binary mode ought to work just as well (except for character set conversion). Certainly a pair of 0's don't know enough to negotiate the proper type, even if they're (for example) both VMS boxes unless labeled mode is used. Terry 2-Jun-96 17:43:27-GMT,2090;000000000011 Received: from spcvxa.spc.edu (spcvxa.spc.edu [192.107.46.27]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA02904 for ; Sun, 2 Jun 1996 13:43:26 -0400 (EDT) Received: from spcvxa.spc.edu by spcvxa.spc.edu (PMDF V5.0-7 #14038) id <01I5FOATE3EO8WVZ9U@spcvxa.spc.edu> for fdc@WATSUN.CC.COLUMBIA.EDU; Sun, 02 Jun 1996 13:43:20 -0400 (EDT) Date: Sun, 02 Jun 1996 13:43:20 -0400 (EDT) From: "Terry Kennedy, Operations Mgr" Subject: Re: auto file transfer mode To: fdc@WATSUN.CC.COLUMBIA.EDU Message-id: <01I5FOATF5ZM8WVZ9U@spcvxa.spc.edu> Organization: St. Peter's College, US X-VMS-To: IN%"fdc@WATSUN.CC.COLUMBIA.EDU" X-VMS-Cc: TERRY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > VMS-to-VMS transfers automatically pop into labeled mode, as they should, and > the results (based on inspection plus DIRECTORY/FULL, etc) are perfect, so I > assume the same will be true of OS/2-to-OS/2 transfers. And of course (back > to VMS) we don't worry that the Kermit on the other end is really Kermit-32, > because it will never send its system ID in the init string. (Putting the > program name and version number in the init string would be going too far...) Note that in some cases labeled->labeled will fail - if the user doesn't have the priv to set the ownership/create the file in the directory, etc. I'd suggest trying it as a non-priv'd user. If this becomes part of the regular Kermit stuff, we may want to change the defaults for some of the labeled options. Also, remember that in labeled mode we don't have a good way to send the real error back to the sender's Kermit because we've already said we will accept the file (there's no provision in the Kermit protocol for fancy error messages once we accept the start of the file) so if you're extending the protocol, this might be a good time to add that (we can add a "accept funky error status during transfers" flag to the just-added system type info, so we don't send errors to Kermits that can't support them). T. 2-Jun-96 17:58:59-GMT,2511;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id NAA04361; Sun, 2 Jun 1996 13:58:51 -0400 (EDT) Date: Sun, 2 Jun 96 13:58:51 EDT From: Frank da Cruz To: "Terry Kennedy, Operations Mgr" Subject: Re: auto file transfer mode In-Reply-To: Your message of Sun, 02 Jun 1996 13:43:20 -0400 (EDT) Message-ID: > Note that in some cases labeled->labeled will fail - if the user doesn't > have the priv to set the ownership/create the file in the directory, etc. > I'd suggest trying it as a non-priv'd user. > Worked fine for me here, but who knows how priviledged I am -- not very, I don't think... > If this becomes part of the > regular Kermit stuff, we may want to change the defaults for some of the > labeled options. > Definitely, if this is likely to bite some people -- or at least recover gracefully from failure to set certain items if the needed privilege is lacking. > Also, remember that in labeled mode we don't have a good way to send the > real error back to the sender's Kermit because we've already said we will > accept the file (there's no provision in the Kermit protocol for fancy error > messages once we accept the start of the file) so if you're extending the > protocol, this might be a good time to add that (we can add a "accept funky > error status during transfers" flag to the just-added system type info, so > we don't send errors to Kermits that can't support them). > Well... We can send a fatal error message (E packet) at any time. There is also provision for a non-fatal information message in the data phase of a transfer (M packet) though this has never been implemented anywhere. Speaking of privilege, do you know what the deal is with Rlogin in VMS? I've got an Rlogin client going now, but I need to "set proc/priv=all". I know that 513 is a "privileged port" in BSD sockets implementations (so therefore in all UNIXes), and I guess UCX, TGV, etc, are imitating BSD in this respect. Exactly which privilege is needed, and is there a way for the system manager to make Rlogin clients not need privilege? Finally, if you ever get a few spare hours there are several things badly needing attention in VMS C-Kermit, that are beyond me, and (typically) nobody else is stepping up, despite incessant cajoling :-) I *have* accomplished some things on my own, though -- VMS C-Kermit now accepts incoming TCP connections, etc... Thanks! - Frank 3-Jun-96 17:44:10-GMT,2078;000000000011 Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id NAA07363; Mon, 3 Jun 1996 13:44:09 -0400 (EDT) Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1) with BSMTP id 8930; Mon, 03 Jun 96 13:43:38 EDT Date: Mon, 1996 Jun 3 13:16 EDT From: (John F. Chandler)JCHBN@CUVMB.CC.COLUMBIA.EDU To: (Frank da Cruz)fdc@WATSUN.CC.COLUMBIA.EDU, (Joe Doupnik)JRD@cc.usu.edu, TERRY@SPCVXA.SPC.EDU, CMG@WATSUN.CC.COLUMBIA.EDU, (Jeffrey Altman)jaltman@WATSUN.CC.COLUMBIA.EDU Subject: Re: auto file transfer mode In-reply-to: fdc@WATSUN.CC.COLUMBIA.EDU message of Sat, 1 Jun 96 20:39:22 EDT Message-id: > it should be stated that this business takes precedence over the WHATAMI > stuff from two years ago, since it is more likely to compensate for a mis-set > FILE TYPE. This is only one-way, though. I.e., once it forces BINARY, there's no corresponding mechanism to go back to TEXT if the user ends one session and starts another, talking to an unlike system. The result is to make Kermit seem more mysterious and unpredictable to the average user. > Kermit-370 probably just needs to send the system ID and nothing more. I've made the update. > "I1", "VM/CMS", 0, NUL, 0, 0, 0, > "I4", "MUSIC", 0, NUL, 0, 0, 0, Now, this is an interesting point. MUSIC actually has DOS-like names nowadays, and even has "owner:" prefixes. In principle, Kermit could send file names in the full form, rather than canonical. However, it doesn't at present, and no one has ever requested that option. Indeed, even CMS now has hierarchical directory structures, though the CUVMB system has made a policy of not allowing them to be used (too buggy in the early releases, I guess), and even when available, these directory named are still used only to map onto ordinary CMS disk mode letters. John 4-Jun-96 1:36:52-GMT,3491;000000000001 Received: from barney.usu.edu (barney.usu.edu [129.123.1.89]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id VAA22972; Mon, 3 Jun 1996 21:36:51 -0400 (EDT) Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556) id <01I5HEC1U7Y88ZZN7T@cc.usu.edu>; Mon, 03 Jun 1996 19:36:44 -0600 (MDT) Date: Mon, 03 Jun 1996 19:36:44 -0600 (MDT) From: Joe Doupnik Subject: Re: Auto-sense, mod to spec To: fdc@WATSUN.CC.COLUMBIA.EDU Cc: JALTMAN@COLUMBIA.EDU, CMG@WATSUN.CC.COLUMBIA.EDU, JCHBN@CUVMB.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU Message-id: <01I5HEC1UAS28ZZN7T@cc.usu.edu> X-VMS-To: IN%"fdc@watsun.cc.columbia.edu" X-VMS-Cc: JALTMAN@COLUMBIA.EDU,CMG@WATSUN.CC.COLUMBIA.EDU,JCHBN@CUVMB.CC.COLUMBIA.EDU,TERRY@SPCVXA.SPC.EDU,JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > 1. We agree that whenever we enter protocol mode, we save the user's > file-type and file-names settings, and restore them upon exit from > protocol mode. Thus any auto-anything that happens during protocol > is not sticky. I think MSK has this characteristic already, implicitly by other means. > 2. The system ID string should be sent only if the sender of it is > prepared to do the automatic mode switching. > >BUT... If it is not sent, something must be sent in its place because >the init string parameters are positional, and we need to design ahead to >allow for addition of subsequent fields. > >Since the system ID begins with a length field, then to indicate that we don't >have one, we can (a) leave it off entirely, as this is presently the rightmost >defined field (so Joe's solution is OK for now), or (b) include a length field >of 0, to indicate there is no system ID, and that the next parameter (not yet >defined) follows immediately. > >But zero translates to space, and we all know what a bad idea trailing spaces >are, and (due to the lack of foresight of whoever designed this thing >originally) the checksum on the S/I/Y packet can itself be a blank. Thus we >could have two trailing blanks that could easily be chopped off in transit. Yes, I too was worried about trailing blanks, even though I stuck them in as placeholders this afternoon. >So let us define a new "system ID" of "anonymous", and its code is "0" (zero). >And let's say that to indicate that "I am not prepared to do automatic mode >switching based on System ID" (e.g. because the user SET TRANSFER MODE >MANUAL), we send "!0" (! = length 1, 0 = anonymous system ID). Done (tonight). >Let us further expand the WHATAMI specification to say that the WHATAMI >field is blank if we do not support WHATAMI, but we do support the system ID >or later fields. (A valid WHATAMI field always has a nonzero -- i.e. not >blank -- value.) WHATAMI field is self describing, in that "bit 5" must be on to say valid, like this (doc clipping): The layout of the (unencoded) WHATAMI field is: Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 +--------+----------+----------+--------+--------+--------+ | 1 | FLAG3 | reserved | FNAMES | FMODE | SERVER | +--------+----------+----------+--------+--------+--------+ The current MSK code says if "bit 5" is off then skip the byte and continue looking (for the auto-sense stuff today). So anything with "bit 5" turned off will do as a filler byte, and we have this byte present to keep the counting straight. >Are we done? :-) Seems that way to me. Joe D. 4-Jun-96 21:28:42-GMT,1641;000000000011 Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id RAA10726 for ; Tue, 4 Jun 1996 17:28:41 -0400 (EDT) Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1) with BSMTP id 1704; Tue, 04 Jun 96 17:26:36 EDT Date: Tue, 1996 Jun 4 17:15 EDT From: (John F. Chandler)JCHBN@CUVMB.CC.COLUMBIA.EDU To: (Frank da Cruz)fdc@watsun.CC.COLUMBIA.EDU, (Joe Doupnik)JRD@cc.usu.edu, CMG@WATSUN.CC.COLUMIBA.EDU, JALTMAN@COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU Subject: Re: Auto-sense, mod to spec In-reply-to: fdc@watsun.cc.columbia.edu message of Mon, 3 Jun 96 19:56:24 EDT Message-id: > OK, two clarifications to the proposal: > > 1. We agree that whenever we enter protocol mode, we save the user's > file-type and file-names settings, and restore them upon exit from > protocol mode. That sounds about right, although there is a possible exception for server mode. E.g., the server can be given a REMOTE SET or REMOTE KERMIT SET. It's not entirely clear to me that those should be erased upon leaving server mode, but it's a minor point. > 2. The system ID string should be sent only if the sender of it is > prepared to do the automatic mode switching. As for Kermit-370, I think we agree that no mode switching will actually be appropriate, but it might as well send the system ID anyway, since that won't hurt anything. Or will it?? John 4-Jun-96 21:35:37-GMT,1993;000000000005 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id RAA11681; Tue, 4 Jun 1996 17:35:36 -0400 (EDT) Date: Tue, 4 Jun 96 17:35:36 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: JCHBN@CUVMB.CC.COLUMBIA.EDU Cc: fdc@watsun.CC.COLUMBIA.EDU, JRD@cc.usu.edu, CMG@WATSUN.CC.COLUMIBA.EDU, TERRY@SPCVXA.SPC.EDU Subject: Re: Auto-sense, mod to spec In-Reply-To: Your message of Tue, 1996 Jun 4 17:15 EDT Message-ID: > > OK, two clarifications to the proposal: > > > > 1. We agree that whenever we enter protocol mode, we save the user's > > file-type and file-names settings, and restore them upon exit from > > protocol mode. > > That sounds about right, although there is a possible exception for > server mode. E.g., the server can be given a REMOTE SET or > REMOTE KERMIT SET. It's not entirely clear to me that those should be > erased upon leaving server mode, but it's a minor point. I agree that Kermit-370 REMOTE KERMIT SET should be a permanent change. Whereas, REMOTE SET should be for the current SERVER session. > > 2. The system ID string should be sent only if the sender of it is > > prepared to do the automatic mode switching. > > As for Kermit-370, I think we agree that no mode switching will actually > be appropriate, but it might as well send the system ID anyway, since > that won't hurt anything. Or will it?? Kermit-370 should send the ID so that it can be reported to the user in C-Kermit and MS-DOS Kermit. However, no mode changes would occur with Kermit-370 unless two Kermit-370s were talking to one another. Jeffrey Altman * PO Box 220415 * Great Neck, NY * 11022-0415 * (516) 466-5495 * 612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344 C-Kermit 5A(191) for OS/2: http://www.columbia.edu/kermit/cko191.html Kermit 95 for Windows 95 : http://www.columbia.edu/kermit/k95.html 4-Jun-96 22:40:34-GMT,1839;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id SAA22084; Tue, 4 Jun 1996 18:40:29 -0400 (EDT) Date: Tue, 4 Jun 96 18:40:29 EDT From: Frank da Cruz To: Joe Doupnik Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, CMG@WATSUN.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, JALTMAN@COLUMBIA.EDU Subject: Re: Auto-sense, mod to spec In-Reply-To: Your message of Tue, 04 Jun 1996 16:32:19 -0600 (MDT) Message-ID: > I think it's unwise to advertise a capability (sic) that one is > not prepared to implement. No telling what the other side will do in > response. Yesterday's modification to the protocol said if the Kermit will > not perform auto-sensing then it should either put no system ident in the > I/S/Y packets or put a !0 placeholder there (meaning, I understand and I > decline on this point). The placeholder is necessary to accomodate future > I/S/Y additions which would appear after this field, and thus !0 is the > recommended change for Kermit-370. > Strictly speaking, this is all correct. In practice (and from a PR point of view), however, it's OK for Kermit 370 to send its ID, because Kermit-370 can never talk to itself (if that ever changes, then we will have to go back and enforce the rule), and so therefore sending its true ID has the same effect on the protocol as sending !0. Meanwhile, there is something to be said for the dramatic impact of seeing the remote operating system name in the file transfer display and transaction log. Nobody else can do (or does) that, especially not when IBM mainframes are involved. So I'd favor pandering to the Gee-Whiz crowd; no sense letting a perfectly good chance at harmless promotion go to waste :-) These days we need all the boosts we can get... - Frank 4-Jun-96 23:58:29-GMT,1447;000000000001 Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id TAA12340; Tue, 4 Jun 1996 19:58:29 -0400 (EDT) Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1) with BSMTP id 2001; Tue, 04 Jun 96 19:57:57 EDT Date: Tue, 1996 Jun 4 19:45 EDT From: (John F. Chandler)JCHBN@CUVMB.CC.COLUMBIA.EDU To: (Joe Doupnik)JRD@cc.usu.edu, FDC@WATSUN.CC.COLUMBIA.EDU, CMG@WATSUN.CC.COLUMBIA.EDU, TERRY@SPCVXA.SPC.EDU, JALTMAN@COLUMBIA.EDU Subject: Re: Auto-sense, mod to spec In-reply-to: JRD@cc.usu.edu message <01I5IMRSKZ0I987ZSZ@cc.usu.edu> of Tue, 04 Jun 1996 16:32:19 -0600 (MDT) Message-id: > I think it's unwise to advertise a capability (sic) that one is > not prepared to implement. No telling what the other side will do in > response. Well, yes, but... Since no variant of K-370 supports dial-out, and the CMS variant is the only one that even implements communication through any device other than the terminal, there's a great deal of development needed before K-370 could actually talk to itself (even leaving aside the fact that the IBM mainframe-style communication won't allow a CONNECT mode for K-370). All in all, it's pretty safe to say that I'm prepared to implement the mode-switching capability as soon as it makes any sense. John