Carsten Bormann <[email protected]> writes:
> Quick question (can’t find in the archives whether that was discussed):
>
> I this YANG-JSON valid for a `binary`?
>
> "base64encodedvalue==“
Strictly speaking it isn't because it's out of range of the base64 encoding
function. I think though it is OK to be liberal in what we accept here because
"base64encodedvaluQ==" is clearly the canonical value in this case, so there is
no ambiguity e.g. regarding string equality.
Lada
>
> Section 6.6 of RFC 7951 points to Section 9.8 of RFC 7950, which points to
> Section 4 of RFC 4648. That says:
>
> 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.
>
> I read that as saying the `binary` should be encoded as:
>
> "base64encodedvaluQ==“
>
> (Q = 010000, e = 011110, only the first two bits are used after “u” has
> supplied six of eight for the last byte, so the rest must be zero.)
>
> Grüße, Carsten
>
> ...
>
> For those who don’t breathe base64, here’s the problem:
>
> a = Base64.decode64("base64encodedvalue==").hexs
> => "6d ab 1e eb 87 a7 72 87 5e 76 f6 a5 b9”
>
> But some bits were *not* zero in the discarded part, so we get:
>
> Base64.encode64(a.xeh) => "base64encodedvaluQ==\n”
>
> Of course, a strict base64classic decoder is not going to accept
> "base64encodedvalue==“ in the first place, because the sentence cited above
> is violated.
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
