I probably *can* support it, but will not. This doesn't mean
that you cannot. I just don't want to see it in a MIME specification.
So to all other implementors, please just don't SAY anything about it.
This is the type of attitude that I think will continue to cause us
nothing but trouble. Sure, we can all just hide our heads in the
sand, however this will not cause the problem to go away.
Please don't think that my comments here are in technical support of
uuencode - personally I don't care much either way. I've yet to have
any problems personally (after > 12 years of use), however I do
understand this is not the universal experience.
Not surprising, given the fact that the Internet definitely tends towards
overlapping pockets of common usage.
The problem is that some of us are in the wrong groups and encounter problems
with uuencode on a regular basis. I certainly do, both in terms of my personal
use as well as in terms of customer support.
As I have said before, we have not made it through a release cycle
(approximately 8 months) yet where we haven't had to tweak our decoder to
handle some additional variant or other. The latest was one that produced long
lines (84 characters) which were then wrapped by an intermediate gateway. It
also didn't use any of the usual termination conditions that most decoders look
for.
We also have encountered, for the first time, someone else's decoder that
doesn't understand the material we produce. Specifically, it doesn't like our
use of grave accents instead of spaces. (Most encoders use grave accents
because space stripping is endemic in some environments and the lost spaces
definitely break some decoders.) I quite frankly don't know what we're going to
do about this one, since there's now no single encoded format we know of that
works for all decoders.
I think that this group has agreed that technically the use of
uuencode is not a good thing. I believe that it has also been
demonstrated that due to the demands put on us by our respective
customers (the real world), we can conclude that this beast is not
going to go away, regardless of how much we wish it so.
As I said before, I disagree with this assessment. Sure, it is going to take a
while. But I've recently been finding customers who are experiencing more and
more problems with uuencode and who are reevaluating their choice of it as a
"standard" encoding. At least two sites of ours have reversed the decisions
they have made in this regard.
As such, I absolutely do not want, and will in fact strongly oppose, any
efforts to standardize anything in this area.
So, what are we going to do? If we continue to ignore the situation,
we will also continue to have potential interworking problems since
there are no well defined ways to send this data. We all seem to be
talking among ourselves about how we want to specify uuencoded
attachments, however nobody want's to talk about it "officially".
Perhaps I'm missing something here, but I don't see how we can have it
both ways - we either have to address this issue or not.
I think unofficial talk is all that's needed and all that there ever should be.
To start with, can we figure out some forum or document we can all
point to (it does not have to be MIME), where we can at least agree on
a way to label such attachments? For those more knowledgable about
uuencode, is there a way where we can identify a version of uuencode
that is less likely to cause problems when running through problem
transports?
I'm sorry, but I think the existance of such a document will do much more
harm than good.
... one has to put up with a little ugliness sometimes
to keep those dang users happy. For better or worse, the CTE solution was
chosen by some implementors and has become entrenched. I'm not trying to
defend their decision, merely living with it.
This is precisely the position we find ourselves in as well. We
certainly don't like it either, however keeping the customers (users)
happy is fairly importantant to our bottom line... :-( :-)
So, since you have solved your problem, and by your own statements you never
have operational problems with UUENCODE, why do you want to see any change
in this area?
Ned