I don't have a problem with having UUENCODE as an optionally supported
encoding (my current implementation of the draft RFC actually supports
UUENCODE), but I must continue to insist on retaining BASE64 as the encoding
of choice. I've simply had too much trouble with UUENCODE personally to
make any other recommendation. The additional argument in favor of the
BASE64 encoding is that it is required by privacy enhanced mail anyway...
I also don't have a problem with having BASE64 as an optionally supported
encoding, I think we both agree that new-style UAs should be able to decode
both BASE64 and uuencode, the extra effort is minimal. I even think we
agree that new-style UAs should allow the user to customize which encoding
mechanism to use on transmission. However, I must continue to insist on
defaulting to a more commonly available encoding mechanism than BASE64.
The question for me both as a nice Internet kind of guy and as a vendor
hoping that a customer will one day want to buy products based on what
we come up with is 'How do we adversely affect the smallest number of
current users of email'. This is rather the whole point of having this
discussion focus on fixing SMTP vs using a real transport for mail.
For the forseeable future, even if I am somewhat optimistic about the
proliferation of our new protocol, I am quite confident that if a randomly
selected user of email tried to send an encoded message to an arbitrary email
address, it would be successfully decoded more frequently if the message was
uuencoded (or even BINHEX'd) than BASE64'd.
The number of emailers with uudecode >> those with BASE64.
The number of emailers with uudecode >> those using EBCDIC.
(And, though I love Jim Galvin dearly)
The number of emailers with uudecode >> >> >> those using PEM.
Furthermore, (though the merits of this decision are another debate) this
group has already decided that MTAs which are not strictly 821 compliant
in their use of 7-bit ASCII (i.e. they use 8-bits) are verboten and to be
discouraged. If an MTA is incapable of passing 7-bit ASCII because an
implementor was lasy and didn't do proper mapping in and out of their EBCDIC
enclave than that MTA needs to be fixed.
Finally, no matter what we say, users sitting behind such a broken MTA have to
pay a hefty price -- their BASE64 encoded data will for the most part only be
understood by users with new-style MTAs.
enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com