Nathaniel Borenstein writes:
Erik M. van der Poel writes:
I disagree. If you recommend particular versions of uuencode,
implementors will be encouraged to use the uuencode that comes with
the OS. When people port the source of such a UA to a different
platform, there is no guarantee that the uuencode version will be OK.
So I think the RFC should say that implementations *must* do their own
uuencoding. This also means that we need to include a full definition
of safe uuencode in the RFC. And if people are worried that
implementing uuencode is too hard, we can even include a free safe
implementation of uuencode in an appendix.
But if we're doing this, we've just given up on the original motivation
(which I never shared) for allowing uuencode, which is that there are
lots of implementations that already exist!
It looks like I have some clarifying to do again. What I meant to say
was that new implementations of RFC-XXXX should incorporate their own
"safe" uuencoding routines, instead of calling the OS' uuencode. This
means that new implementations will send relatively "safe" uuencode.
The whole point of including uuencode in the new RFC is so that old
receivers (not new senders) can use the OS' uuDEcode BY HAND.
Now what does "safe" mean? A safe uuencode definition is that which is
used by the latest version of uuencode.
Erik