Dne 27. 02. 23 v 14:31 Carsten Bormann napsal(a):
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”).
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
