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

[Carsten Bormann <[e-mail]>]

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”).

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”?

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