At 7:31 PM 12/19/94, Mr Rhys Weatherley wrote:
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.
That's certainly why I do it as a CTE.
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.
Indeed. In fact, the Apple registry is immense, far larger than the
IANA's, and so far more useful (at least for Mac files). When doing a
mac-to-mac transfer, the MIME content-type is completely irrelevant if
BinHex is being used; and that's why BinHex makes sense as a content-type
instead of a CTE.
Uuencode, on the other hand, has no typing information at all attached to
it. The "extra information" alluded to by another poster is a filename and
some permission bits; hardly enough to make the real content-type
superfluous.
Some people seem to be interested in making (already iffy) uuencode as
unpleasant as possible, in order to kill it as quickly as possible. While
I certainly sympathise with that as a developer, as a vendor it's
untenable. I have to try to make uuencode work as well as I can, all the
time warning people that it's really not going to work all that well no
matter what I do.
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."