WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (02/10/89)
(I'd be more in favor of dropping TENEX mode from FTP.) Barry, I hope you were just being flippant, but I saw no smiley there... So, lest someone might take that comment seriously, let's make it clear that TENEX is just an alias for TYPE L 8 (not TYPE L 32, please!). But, if you really are seriously suggesting to drop TYPE L 8, then we have a problem. How else can you send bytes from one machine architecture to another? Certainly TYPE I (image) isn't a universal solution, even between machines of the same word size and operating system! --Frank
VAF@SCORE.STANFORD.EDU (Vince Fuller) (02/11/89)
(I'd be more in favor of dropping TENEX mode from FTP.)
I hope you were just being flippant, but I saw no smiley there... So,
lest someone might take that comment seriously, let's make it clear
that TENEX is just an alias for TYPE L 8 (not TYPE L 32, please!).
But, if you really are seriously suggesting to drop TYPE L 8, then we
have a problem. How else can you send bytes from one machine
architecture to another? Certainly TYPE I (image) isn't a universal
solution, even between machines of the same word size and operating
system!
There's some confusion here as to what "TENEX mode" in FTP means. Back in the
old days, when the majority of ARPANET (pre-Internet) systems were TENEX's and
TOPS-20's, a means was devised for doing transparent file copying between such
systems. This became known as "TENEX mode", and is a actually a combination of:
TYPE L 36 (36-bit packing of the bytestream)
STRU P ("Paged" structure)
MODE S ("Stream" mode - actually this doesn't really matter)
In more recent times, the UNIX FTP client started calling TYPE L 8 "TENEX
mode", probably because it's the type of transfer used to retrieve a class of
shareware that is kept on a certain, popular TOPS-20 host.
In any case, I believe Barry is proposing the drop the original "TENEX mode"
from the FTP spec, not to drop TYPE L 8. I suppose this would consistant with
the philosophy that FTP should only implement the least-common-denominator of
pushing bits around and is sort of moot anyway, since the only machines that
implement this are not likely to hang around for more than a few more years.
Why not just make all non-interoperable FTP operations subject to the "SITE"
command? That's what it's there for. Why not "SITE VMS MODE RMSFILE", or
something like that? This will make implementation of "intermediary" machines
to store system-specific filetype difficult, but it will solve the immediate
problem of how to get systems running a common OS to transfer files that are
native to that OS.
--Vince
(P.S. The only reason I know about the two definitions of "TENEX mode" is
through experiencing similar confusion when someone asked me, onece the
de facto TOPS-20 FTP maintainer, about "TENEX mode" on UNIX systems -
"TENEX mode on UNIX systems??" I was a little surprised to hear about such
a thing until it was explained to me what the speaker meant by "TENEX mode")
-------jbn@glacier.STANFORD.EDU (John B. Nagle) (02/12/89)
In article <WANCHO.12469460754.BABYL@WSMR-SIMTEL20.ARMY.MIL> WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") writes: > > (I'd be more in favor of dropping TENEX mode from FTP.) > We used to call this ("TYPE L 8") "byte" mode in an implementation of FTP that I controlled. Unfortunately, "Tenex" has been enshrined in too much software. But I would suggest that "byte" be implemented as an alternate name for the mode. Incidentally, remember, FTP client implementors, when doing directory operations, always switch back to ASCII mode for the directory transfer if you're in some other mode. John Nagle
bzs@pinocchio.UUCP (Barry Shein) (02/12/89)
Vince is correct, I was referring to the 36-bit mode used between two PDP10 systems when I made the comment about TENEX mode. And no, I don't honestly think anyone should bother to drop it, what I meant was that it shouldn't be used as a precedent. -Barry Shein, ||Encore||
WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (02/12/89)
Vince, At the risk of belaboring the point, but only to avoid rewriting history, I must defer to you as the former maintainer of the FTP server we use here as the more knowledgeable on FTP matters (I'm just a late comer). However, I don't ever recall seeing the "tenex" command (not mode) (on Unix and bsd-derived systems only) as an alias for PAGED mode file transfers. It has always sent TYPE L 8 to the remote host and conditioned the local host to receive a binary file. PAGED mode was originally called XTP (eXperimental TENEX PAGED) mode by Bob Clements in RFC 683. The tenex command first appeared in some early version of user ftp in bsd4.1 or so. As far as I can tell, the tenex command was never documented in any RFC related to FTP, although it should have been because of a certain broken implementation which sent TYPE L 32 and still causes us no end of complaints and misunderstandings. On the other hand, let's not confuse TENEX with PAGED mode either. PAGED mode was originally devised for possibly holey TENEX/TOPS20 file transfers, and as long as we have another TENEX/TOPS20 machine to talk to, let's keep PAGED mode around. In spite of the fact that Barry says we shouldn't use it as a precedent, I propose that PAGED mode be considered a generic mode to transfer an exact copy of a file, including FDB and other information between two machines with the same operating system. Note that in the specification for PAGED mode, the exact format of the attribute and descriptor blocks is not given. It could easily be adapted by mutual agreement between user and server ftp implementors to the VMS problem currently under discussion. When it is used between VMS systems, it is understood to mean TYPE L wordsize instead of TYPE L 36 (all else being left the same). --Frank
braden@VENERA.ISI.EDU (02/14/89)
Why are people talking about "Tenex mode in FTP", when that is just a user command in one particular implementation of a User FTP? There is no "Tenex mode" in the FTP protocol, RFC-959. If you don't like the command, complain to the people who wrote and maintain the operating system in which is appears. I'm sure you know the address. Bob Braden