This was discussed in late 2021. I switched from:
base64encodedvalue==
to:
BASE64VALUE=
in all my drafts then. Which document are you looking at?
Kent
> On Feb 27, 2023, at 9:24 AM, Carsten Bormann <[email protected]> wrote:
>
> On 2023-02-27, at 15:04, Ladislav Lhotka <[email protected]> wrote:
>>
>> Unlike non-alphabet characters, RFC 4648 doesn't say that such a character
>> in encoded data is invalid.
>
> Not explicitly, but it also gives you an algorithm for arriving at the
> encoded value that never can result in the characters that I consider invalid
> [1]:
>
> When fewer than 24 input
> bits are available in an input group, bits with value zero are added
> (on the right) to form an integral number of 6-bit groups.
>
> Note the explicit “with value zero”.
>
>> FWIW, my implementation (Yangson) uses Python standard library base64 that
>> accepts it without complaints even with validation turned on:
>>
>>>>> import base64
>>>>> base64.b64decode("ue==", validate=True)
>> b'\xb9'
>>
>> So I assume the authors consider this input valid, and I saw no reason to be
>> concerned about it.
>
> Thank you — that was the kind of input I was looking for.
>
> Now what do other implementations do?
>
> Grüße, Carsten
>
> [1]: https://www.rfc-editor.org/rfc/rfc4648#page-6
>
> And the missing [2] from my previous message:
> [2]:
> https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
