Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cc.utah.edu!cc.usu.edu!jrd
From: JRD@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Re: Binary file transfers with MS Kermit
Message-ID: <15267@cc.usu.edu>
Date: 13 Dec 89 03:26:34 GMT
Lines: 37

Dion,
	Binary mode and Control-Z are separate problems. MS Kermit provides
a command specifically to deal with Control-Z, and it does not have a SET
FILE TYPE BINARY command.
	Having said that in nice upper case let me squirm around a little!
Version 3.0 of MS Kermit (due out shortly...) does have SET FILE TYPE BINARY,
and a bunch more like it. The implementation is to permit translation of
text files to other character sets using a standard character set on the
wire. TYPE BINARY says send the file verbatim and include in the file
attributes packets the notation that the local user is doing so. TYPE TEXT
says it's ok to translate ends of records to CR/LF, and more. Well, MS DOS
has no concept of records and CR/LF thus translates to CR/LF. The "and
more" part says to let the user say SET FILE CHARACTER-SET {choice of many}
and that would make sense only if the file were text. Again the attributes
packets note that this is what the file sender intends, and thus lets the
file receiver match up.
	All this is for MS Kermit, and has nothing to do with Procomm or
other products implementing the Kermit protocol. There is no question
however that the fancier aspects of SET FILE exist on PCs only in MS Kermit
(for now, because this stuff was just recently invented and I'm just
implementing it). 2.32/A is the latest release, Jan 89, and 3.0 is due
out this month (fingers crossed).
	So, MS DOS has no distinction between text and binary files, period.
Applications can do as they please with bit patterns. The file sender is
the one needing to be commanded by SET FILE TYPE BINARY and for MS Kermit
that need not (and can't until v 3.0) be done. Only file senders emit
attributes packets which is where information like this gets across the wires.
	As a matter of small interest, packet formation is the same whether
or not the file is binary or text. On hosts having a concept of records they
have to stick in a CR/LF for text files, or not for binary files. On MS DOS
its all the same no matter what. 7 or 8 bit characters can be sent on the
wire and the 8 bit kind will be encoded to 7 bits if one side says Please
do (normally only if the useless Parity bit is on). Thus, the Kermit protocol
provides a virtual 8 bit channel.
	I hope this clarifies a commonly misunderstood topic, and one that
is important to us.
	Joe D.