< I'm looking for a little guidance from other MIME implementors in regards
< to uuencode. I am quite familiar with the reasons why uuencode is persona
< non grata in this working group, so there's no need to point them out yet
< again. However, I still need to support this vile habit for reasons of
< backwards compatibility with older non-MIME software, yet hopefully make
< it easy for MIME implementations that understand uuencode to automatically
< pick out the data and decode it.
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.
Consider the binhex format which has been commonly used with Mac's. At a
certain level, it's identical to uuencode: it has an encoded content, plus
additional information about the file the content is to be stored into.
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.
So too, uuencoded attachments should be handled using Content-Type: uuencode
and NOT as another Content-Transfer-Encoding!
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?
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony