Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!gitpyr!thomps
From: thomps@gitpyr.gatech.EDU (Ken Thompson)
Newsgroups: net.micro,net.micro.atari16
Subject: Re: New way to post binaries
Message-ID: <2462@gitpyr.gatech.EDU>
Date: Wed, 22-Oct-86 09:58:37 EDT
Article-I.D.: gitpyr.2462
Posted: Wed Oct 22 09:58:37 1986
Date-Received: Fri, 24-Oct-86 00:16:58 EDT
References: <2035@dalcs.UUCP>
Distribution: net
Organization: Georgia Institute of Technology
Lines: 64
Summary: No new standard
Xref: mnetor net.micro:6303 net.micro.atari16:2709

In article <2035@dalcs.UUCP>, silvert@dalcs.UUCP (Bill Silvert) writes:
> Here are some opinions about the problem of posting binaries, along with
> a draft solution.  There should be some discussion on the net before it
> gets implemented.
> Sources are no substitute for binaries, since not everyone has the same
> compiler, or even language, on micros.
> Binaries have to be encoded as ASCII files.  But there is no reason why
> we have to use uuencode!  There are evidently problems with it, and we
> should feel free to invent an alternate encoding method which avoids the
> problems with uuencode.  These problems, aside from the minor one that
> uuencode is designed for th Unix environment, are that some characters
> (such as curly braces {}) do not make it through all nodes unscathed
> (IBM machines and others with EBCDIC codes appear to be the culprits),
> and for long files the posting have to be combined in an editor.
> Another problem is that udecode is a complicated program which a lot of
> users have trouble getting or rewriting.
> I propose that we develop an encoding method for microcomputers that
> meets these requirements:
> > So simple that users can easily learn the protocol and write their own
> version of the decoding program.  Uudecode is relatively easy to write
> in C, but gets tricky in languages that do not have low-level bit
> operations.
> > Moderately compact, to keep the traffic volume down.
> > Reasonably good error trapping to check for damaged files.
> > Convenient to use, preferably not requiring the use of an editor even
> for multi-part postings.
> 
I, for one, am strongly opposed to trying to develop a new "standard"
decoding scheme. For one thing, it will be next to impossible to get
agreement from such a large group on what it should be. The effort will
cause more problems and confusion than we already have. 

I have never experienced the problems with curly braces but it is possible
I suppose that we don't ever get messages that pass through EBCDIC machines
here. Certainly, I have never gotten any C source that had the curly braces
corrupted. 

I have versions of uudecode in turbo pascal, c , and microsoft basic. This
is pretty wide availability and the basic while slow should be easily 
adaptible to most machines. I don't think there will be too many problems
getting a version. Just ask in net.sources.wanted.

The problem with having to use the editor has nothing to do with uuencode/uudecode. The problem is that some news software running on some machines on the net
truncate files longer than 64K bytes. Unless the mail software is changed,
you will always need to get rid of the mail header/signature information
put in by mail as this is ascii too. You will probably have to do this
with an editor. I failed to find this task difficult.

I don't know about other sites, but 99% of the problems we have here are
files which are corrupted in transit, either because the sender posted
files larger than 64K and they got truncated or some of the information
was just corrupted in transit. A new scheme is not going to fix this. 

I vote that we stick with uudecode/encode. If you have problems with these,
I am sure someone on the net will be glad to help you get them worked out.
I receive files all the time that have been arced and then uuencoded and
am able to reverse the process without problems.


-- 
Ken Thompson  Phone : (404) 894-7089
Georgia Tech Research Institute
Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps