Re: base64 behavior is not MIME compliant

[Marc Horowitz]

"Richard M. Stallman" <address@hidden> writes:

>>     I received a piece of email which passed through an older MTA.  This
>>     MTA inserted a ! and a newline after every 1000 characters of a very
>>     long line of base64-encoded data, which used to be common behavior.
>>     When Gnus tried to display this email, it failed, because the !
>>     characters were not recognized as valid base64 encoding.
>
>> Maybe I misunderstood what you were asking for.  I thought you
>> were asking us to make additional base64-decode-region signal
>> errors in cases where currently it does not.  But now it looks
>> like you are asking for it to accept input that now gives
>> an error.

I'm sorry I was confusing.  To quote my earlier email:

    I believe the best fix is for base64-decode-region to take an optional
    argument which specifies how liberal it should be about it's input,
    defaulting to the current behavior, and for Gnus to use this argument.

Defaulting to the current behavior should certainly not mean
signalling errors in new cases.  You are correct that I'm asking for a
behavior variant which would result in more input being accepted.  If
this variant became the default, I would not object, but I would
certainly understand if you did not want to change the default
behavior.

>> Could you give a self-contained description of the change that you are
>> requesting in the behavior of this function?

For the purposes of reading mail, it is valuable to ignore all
characters not part of the base64 character set when decoding.  So, my
minimum proposal would be for base64-decode-region to ignore all
unknown characters, instead of signalling errors in this case.

It would be more generally useful to provide three forms of the
base64-decode-region function, either by having three functions, or
one with an optional argument:

    Form 1: all characters not part of the base64 character set would
    be ignored.

    Form 2: any character not part of the base64 character set would
    cause an error to be signalled.

    Form 3: any character not part of the union of the base64
    character set and the whitespace characters would cause an error
    to be signalled.

Form 3 is the current observed behavior.  I believe there is a need
for Form 1, to make mail reading work more smoothly.  Form 2 mainly
exists for completeness.

                Marc