Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Ladislav Lhotka <[e-mail]>]

Dne 27. 02. 23 v 14:31 Carsten Bormann napsal(a):
> 
> On 2023-02-27, at 12:57, Ladislav Lhotka <[e-mail]> wrote:
>>
>>> 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.
> 
> Right.
> 
>> 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.
> 
> Well, this is the essence of my question (not sure about the part about string equality, though).
> 
> draft-iab-protocol-maintenance [0] takes the position that the Postel principle, while historically a good way to implement protocols and get interoperability going, is not to be misunderstood as a mandate for the evolution of protocol ecosystems — protocols are free to be strict, lest they turn into soup (“Protocol Decay” [1]: “...a chain reaction that can create interoperability problems over time”).

Section 9.1 in RFC 7950: "values in the data tree are conceptually 
stored in the canonical representation", and also "XPath expression 
evaluations are done using the canonical form". If implementations obey 
these rules, and since the canonical form for the binary type is 
unambiguous, I don't see much potential for interoperability problems. 
In essence, it's like representing number 17 as +17.

> 
> I’d like to know whether, on issues like this, YANG is more on the strict side or on the soup side — what do YANG implementations actually do, and what do we want YANG implementations to do?  Is there an implicit “MAY send invalid last character”, which is no different from a “MUST accept invalid last character”?

Unlike non-alphabet characters, RFC 4648 doesn't say that such a 
character in encoded data is invalid.

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.

Lada

> 
> Background: I’m proposing to add a few control operators to CDDL, including for handling base64classic [2], and in my PoC implementation was of course implementing a strict interpretation, only to be struck by the first example in an RFC I was pointed to.
> 
> Grüße, Carsten
> 
> [0]: https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
> [1]: https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-12.html#name-harmful-consequences-of-tol
> 

-- 
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67