Excerpts from mail: 24-Apr-91 Re: Comments on Draft RFC Bill
Janssen(_at_)parc(_dot_)xerox(_dot_) (1710)
I also like Vincent's notion of dropping HEXADECIMAL in favor of BASE64
or BASE85. Do we then assume that basically every UA is able to deal
with BASE64 (via free code, etc.)? I believe that this would then
quickly make UUENCODED obsolete.
I think this is completely plausible. I wrote a quick implementation of
all 3 encodings (base64, hex, and quoted-printable) and it took about
300 lines of code. I can imagine a much smaller implementation, too.
(Unfortunately, Bellcore is VERY reluctant to release such things, so
don't bother asking for the present, but the ease of implementation
convinces me that public domain versions will be quickly forthcoming.)
I also feel that there should be the standard Content-Encoding
"COMPRESSED", for which I do not have a rigorous definition, but which
would mean something like "run through UNIX 'compress' (and then encoded
with BASE64?)". I appreciate the legal tangles with compress, but also
know there's a lot of copies out there. Of course, perhaps a standard
compression routine could also be donated, and made freely available, so
that it is not necessary to use UNIX compress.
I guess that I'm pretty sympathetic in principle, but I see the "legal"
tangles as harder than you imply. One possibility is using Ullman and
Jung's "LZJU90" compression algorithm, for which he Robert recently sent
me a description including an implementation. I fear I'm not really
technically competent to evaluate its suitability, however. Perhaps,
Robert, you should post it to this list? (You might want to leave out
the implmentation for the purposes of discussion, though it is certainly
good to know that a public-domain implementation exists.)
As I've worked to develop a "consensus" RFC, I've found that lots of
things I used to feel strongly about have become less important, in my
eyes, than reaching a consensus. For example, I no longer feel strongly
about whether or not we have a compressed encoding -- I'll happily go
along with it if a good spec can be made available. In general, I think
that reaching consensus is more important than most of the remaining
open details. But I still feel VERY strongly that Content-Encoding
should be a very simple mechanism. In particular, the idea of nested
encodings strikes me as overly and unnecessarily complicated, and
offering little or nothing in the way of payoff.
Sure, lets trade hexadecimal for compressed, if we can define
"compressed" properly. But that's still a small enough number of
encodings that I see no reason we should ever need to nest or cascade
them.