Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!VAX.BBN.COM!ado
From: ado@VAX.BBN.COM (Buz Owen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP Logical Byte Sizes
Message-ID: <8806091207.AA05785@ucbvax.Berkeley.EDU>
Date: 8 Jun 88 05:50:05 GMT
References: <WANCHO.12404639269.BABYL@SIMTEL20.ARPA>
Sender: uucp@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

In addition to being useful with 36 bit pdp10 and related machines, local byte
size 8 is useful with the BBN C/70, which has a 20 bit word and a 10 bit byte
size.  While a discussion of choices of reasonable machine word sizes, and
important or unimportant machine architectures would be inappropriate (and
boring, or maybe annoying) on this list, type L 8 is useful to tell the C/70 to
send just the low 8 bits of each byte, a common type of file on the C/70 --
what you normally get as output from a C program that writes an 8 bit binary
file -- or store such a file.  Using Image mode instead, you get the unused
zero bits sent through the net, wasting network bandwidth and machine cycles,
as the C/70 laboriously repacks bits into 8 bit bytes -- and then have to
run a program to strip the bits out at the other end.

So for both the C/70 and pdp10 type architectures, type L 8 tells the machine
to skip over unused bit positions -- the pdp10 put these bits at the end of
each word, the C/70 puts them in the high order position of each byte.  Thus
local byte size is important if you want to assure compatibility with possible
"odd" machines in the future, or with existing ones you know you need to
communicate with already.

User and server FTP's for 8 bit machines sometimes do not initially implement
even type L 8 because the author knew that there was no special local
interpretation of for it, i.e. that it would be treated the same as image, and
therefore deemed it unnecessary.  But it eventually has to be added in order to
talk to odd machines which do place an interesting -- i.e.  different than
image -- interpretation on it at the other end.  To be general, at least any
local byte size that seems equivalent to type image ought to be accepted by the
server and settable by the user process, and then treated identically to type
Image -- this costs almost nothing in the implementation.  As far as I know,
only a few cases really seem to be needed.

On an 8 bit machine, multiples of 8 seem like they might be equivalent to
image, but then since the spec does not say a particular local byte type means,
it being a local matter, it is hard to rule out that you might someday need to
talk to a machine that needs to be told "type L 5".  What should this mean on a
an 8 bit machine?  The user ftp "quote" command is a reasonable hedge against
this unlikely case except that some user ftp processes withhold the type
command and send it just before the "stor" or "retr" command.

Buz