RFR 8025003: Base64 should be less strict with padding

[Bill Shannon]

Xueming Shen wrote on 10/25/13 15:19:
> On 10/25/13 2:19 PM, Bill Shannon wrote:
>> If I understand this correctly, this proposes to remove the "lenient"
>> option we've been discussing and just make it always lenient.  Is that
>> correct?
> 
> Yes. Only for the mime type though.

That's fine.

>> Unfortunately, from what you say below, it's still not lenient enough.
>> I'd really like a version that never, ever, for any reason, throws an
>> exception.  Yes, that means when you only get a final 6 bits of data
>> you have to make an assumption about what was intended, probably padding
>> it with zeros to 8 bits.
> 
> This is something I'm hesitated to do. I can be lenient for the padding end
> because the
> padding character itself is not the real "data", whether or not it's present,
> it's missing or
> it's incorrect/incomplete, it does not impact the integrity of the data. But to
> feed the last
> 6 bits with zero, is really kinda of guessing, NOT decoding.

I understand.  And if the people who write spamming software knew how to
read a spec, we wouldn't have this problem!  :-)

Still, there's a lot of bad data out there on the internet, and people
want the software to do the best job it can to interpret the data.  It's
better to guess at the missing 2 bits of data than to lose the last 6 bits
of data.