RFR 8025003: Base64 should be less strict with padding

[Bill Shannon]

Xueming Shen wrote on 11/12/2013 09:24 PM:
> On 11/12/13 8:21 PM, Bill Shannon wrote:
>> Xueming Shen wrote on 11/12/2013 04:25 PM:
>>> On 11/12/2013 03:32 PM, Bill Shannon wrote:
>>>> This still seems like an inconsistent, and inconvenient, approach to me.
>>>>
>>>> You've decided that some encoding errors (i.e., missing pad characters)
>>>> can be ignored.  You're willing to assume that the missing characters aren't
>>>> missing data but just missing padding.  But if you find a padding character
>>>> where you don't expect it you won't assume that the missing data is zero.
>>> "missing pad characters" in theory is not an encoding errors. As the RFC
>>> suggested, the
>>> use of padding in base64 data is not required or used. They mainly serve the
>>> purpose of
>>> providing the indication of "end of the data". This is why the padding
>>> character(s) is not
>>> required (optional) by our decoder at first place. However, if the padding
>>> character(s) is
>>> present, they need to be correctly encoded, otherwise, it's a malformed base64
>>> stream.
>> I think we're interpreting the spec differently.
> I meant to say "The RFC says the use of padding in base64 data is not required
> nor used, in some circumstances".
> I interpret it as the padding is optional in some circumstances.

It's never optional.  There's two specific cases in which it's required
and one specific case in which it is not present.