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 <fdc@watsun.cc.columbia.edu>; 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 <JRD@cc.usu.edu>
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
> "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)
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)
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 <fdc@WATSUN.CC.COLUMBIA.EDU>; 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,
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 <fdc@WATSUN.CC.COLUMBIA.EDU>; 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,
> 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
<CMM.0.90.4.833675962.fdc@watsun.cc.columbia.edu> of Sat, 1 Jun 96 20:39:22
> 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)
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 <fdc@watsun.CC.COLUMBIA.EDU>; 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,
> 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,
