> On Oct 22, 2019, at 16:48, Michael Richardson <[email protected]> wrote: > > Signed PGP part > > In answering DISCUSSes on BRSKI, I came up the question of do the > YANG-serialization-to-JSON rules specify which base64 (original > or urlsafe) encoding is to be used for “binary" types?
Legacy (RFC 4648 Section 4 = non-URL-safe, with padding). Look at the examples, which give it away by always ending in == :-) > RFC8366 only references RFC7950, which only peripherally mentions JSON, but > it does say: > > 9.8.2. Lexical Representation > > Binary values are encoded with the base64 encoding scheme (see > Section 4 in [RFC4648]). There it is. The YANG-to-JSON rules are in RFC 7951. 6.6. The "binary" Type A "binary" value is represented as a JSON string -- base64 encoding of arbitrary binary data. The representation is identical to the lexical representation of the “binary" type in XML; see Section 9.8 in [RFC7950]. So this is legacy, too. > 9.8.3. Canonical Form > > The canonical form of a binary value follows the rules of "Base 64 > Encoding" in [RFC4648]. > > but maybe this only applies to XML-serialization.... searching further: > > So, why doesn't RFC8366 reference: > https://datatracker.ietf.org/doc/rfc7951/ No idea. But then, RFC 8366 says The voucher artifact is a JSON [RFC8259] document that conforms with a data model described by YANG [RFC7950], is encoded using the rules defined in [RFC8259], and is signed using (by default) a CMS structure [RFC5652]. which is pretty much devoid of meaning. > I wonder if this is worth an errata clarifying this for RFC8366? Yes, but maybe the WG should decide first what was intended… Grüße, Carsten _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
