On 2023-02-27, at 12:57, Ladislav Lhotka <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
