Uuencode implementations also differ widely in their (in)ability to work
in a pipe, which can be a problem if you want to write an implementation
that simply pipes a body through uudecode. That's another way in which
uuencode/uudecode are "non-standard".
Ok.. that's a little problem. It's just as easy to embed uu{en,de}code
in a program as it is to embed Base64. In fact it might be the same
actual code, but different encoding tables. At any rate the user
agent we're developing includes uu{en,de}code embedded in the program.
It was no trouble to do since it just slid right in. (Hadda do this
since the UA is also portable to PCs and Macs).
I have no qualms with supporting Base{64,85}. Technically they are
better than uuencode. However uuencode is very very strongly
entrenched and widely implemented.
One time I read a story from Dave Crocker about some social engineering
he tried putting into RFC-822. Generating addresses like
To: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
were encouraged over
To: (Nathaniel Borenstein) nsb(_at_)thumper(_dot_)bellcore(_dot_)com
or To: nsb(_at_)thumper(_dot_)bellcore(_dot_)com
Since the first looks much nicer. But it didn't work.
I mention this because your stance on uuencode smacks of this
sort of social engineering.
Hmm.. I haven't noticed. Am I the only person supporting uuencode?
If so I'll shut up now..
David