[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"
Nic
Re: base64 behavior is not MIME compliant, Arne Jørgensen, 2005/07/05