Re: base64 behavior is not MIME compliant

[Nic Ferrier]

Ken Raeburn <address@hidden> writes:

> On Jul 5, 2005, at 18:10, Nic Ferrier wrote:
>> 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"
>
> Except "this extra trick" is specifically outlined as an option in the 
> base64 spec (RFC 3548), and MIME invokes that option.  So proper "MIME 
> base64 decoding" would require this extra step of throwing away 
> characters that are not part of a base64 encoding, and then making a 
> second pass with the strict base64 decoder.  In fact, as I read RFC 
> 3548 section 2.3, the CR/LF line break sequences in MIME messages are 
> not part of the base64 alphabet, and therefore 
> fns.c:IS_BASE64_IGNORABLE already implements a limited form of what 
> Marc is asking for.

You're quite right - my view of what a base64 decoder should do is
based on previous implementation rather than what the spec says (mea
culpa).

Anyway - 2045 (the last MIME/base64 spec I was aware of) says this:

   The encoded output stream must be represented in lines of no more
   than 76 characters each.  All line breaks or other characters not
   found in Table 1 [the acceptable alphabet table] must be ignored by
   decoding software.  In base64 data, characters other than those in
   Table 1, line breaks, and other white space probably indicate a
   transmission error, about which a warning message or even a message
   rejection might be appropriate under some circumstances.

So this spec suggests that the base64 decoder should optionally error
or throw an exception or call a supplied handler or something.


How about I write some advice to just throw unwanted characters away
for base64-decode-xx?

Different advice could be maybe be used when errors are needed.

I'm happy to do this if someone wants it - advice is fairly easy to
include in stuff without it necessarily being in Emacs.

I'll do it on my train journey to work tommorow morning.



Nic