On Mon, 19 Dec 1994 hansen(_at_)pegasus(_dot_)att(_dot_)com wrote:
I don't understand why uuencode is even being considered as a
Content-Transfer-Encoding by anyone. A uuencoded file has more information
attached to it than just the encoded contents; it also has a filename and a
set of permissions. It isn't a way of encoding an arbitrary content; it's a
way of encoding a file.
Granted. I believe the reason why it was put into CTE was so that MIME
implementations that understand it could use the Content-Type line as a
guide for what to do with the file after decoding. e.g. a uuencoded GIF
can be displayed directly by the UA if the UA knows that it is image/gif.
It could guess from the filename I suppose, but who wants to guess when
one can be told? :-)
Now, how is binhex treated within MIME? As Content-Type:
application/mac-binhex40! It's not a CTE at all! There was once a lot of
discussion about treating binhex as another CTE, but it all went away as
people finally came to realize that it doesn't work that way.
I know very little about Mac formats, and binhex in particular, but don't
they have extra resource information attached which specify file types
within Apple's Mac registry? Thus, the need for an explicit type
indication for binhex may not be as great on the Mac platform.
So too, uuencoded attachments should be handled using Content-Type: uuencode
and NOT as another Content-Transfer-Encoding!
Really, I don't care whether it is done as CT or CTE. What interests me
is that there is some way of tagging the content in an unambiguous
fashion. Since "CTE: x-uuencode" appears to be in wide use, I'll support
that to interoperate with other people's software. Whether CT might be
"more pure" is irrelevant to me. We're talking about something sitting on
the edge of acceptability, so purity doesn't matter as much as "it works".
For those of you who try and handle a CTE of uuencode or x-uuencode: What do
you do with the extra information that uuencode has in its header? Do you
just ignore it? Or do you blindly pass the content body to the uudecode
program? And when you generate it, what do you put in the uuencode header?
I plan to extract the information and treat it like Content-Disposition.
That is, present the filename as the default save filename for the body
part. The permissions will be tossed in the bit bucket because they are
meaningless to Microsoft Windows which I'm writing for.
When I generate the uuencode header, it will probably be as the result of
some "attach file" operation so I'll have a filename handy all ready to
add (normally this filename would go into Content-Disposition). If it
comes from somewhere else, I'll probably prompt for a name or make
something up. The permissions will be set to some default value like
"600". The important thing is to make it look close enough to normal
that older uudecode's don't notice the difference. MIME implementations
are free to toss anything they don't need.
I don't see what the hassle is Tony.
The interesting thing about supporting uuencode is not the header
information. It is the junk that comes after. This is where
implementations differ and cause heartaches for automatic decoders.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"