< From: RCB(_at_)3k(_dot_)com (Chris Bartram)
< uuencode only give the file a filename - usually unix-centric; a receiver
< still has to guess at the real filetype. At least using it as a CTE lets
< you accurately pass the descriptive info to the receiver (for MIME UAs),
< while non-MIME UAs can still take their best shot - which they're doing
< nowadays anyway.
< From: Mr Rhys Weatherley <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
< 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? :-)
The actual content type information can be easily passed as a parameter to
< 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.
There are multiple Mac formats. (See RFC 1740 for further information.) Only
some of them have the extra resource information. AppleSingle does not.
AppleSingle is sent as application/applefile with other parameters
indicating other information.
< I don't see what the hassle is Tony.
I use a number of different MIME implementations. As far as I can tell, none
of them make it easy to add support for a new content-transfer-encoding,
while all of them make it easy to add support for a new content-type. If you
send me mail with an attachment encoded with uuencode, my MIME mailers won't
be able to automatically handle it! I have to go back outside of MIME to do
something with the attachment. Instead of making life easier, you've
actually made it more difficult.
As a counter example, consider binhex, which is another encoding that has
been commonly used on Mac systems for years. It has been decided that the
best way to send an attachment encoded using binhex is to use
application/mac-binhex40 with an additional parameter indicating the name of
the file. (See RFC 1741 for further information.) This model works well.