[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: base64 behavior is not MIME compliant

From: Nic Ferrier
Subject: Re: base64 behavior is not MIME compliant
Date: Tue, 05 Jul 2005 23:10:33 +0100

Marc Horowitz <address@hidden> writes:

> "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.

Why can't you just pre-parse the data parsed to the base64 decoder? I
believe that's the correct behaviour. A base64 decoder should decode
base64, not "base64 but also it does this extra trick if you wave your
hand in the air"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]