Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AA7120152 for ; Tue, 22 Oct 2019 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-6oi61vv0mN for ; Tue, 22 Oct 2019 07:48:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA580120013 for ; Tue, 22 Oct 2019 07:48:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AEDBB3897A for ; Tue, 22 Oct 2019 10:45:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D29498F for ; Tue, 22 Oct 2019 10:48:12 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] which base64 for RFC8366... original! X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 14:48:16 -0000 --=-=-= Content-Type: text/plain 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? 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]). 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/ 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]. AHA, so it should be original base64, even though the first paragraph is a bit ambiguous, it does refer to 7950, which is not ambiguous. I wonder if this is worth an errata clarifying this for RFC8366? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2vFqwACgkQgItw+93Q 3WVksggAqXn8syrba2R6+/zzq72hc8wVNSTJzQx8tbMqQT4zjEiv1TNmThMK3bN/ nMFG8lYRQhghZeTijA+30q7dq8FD3lIu9lDo1GeLgkNSLkuM7W4Df/nXDiUYqEa0 Jk7SRtI3Gn3gG76MPRDc2wH3YP9k7HJj4M9CqJvluCIjOGf82kMMwvehjMOlKrEE Qf94PWQwhFF05T0KeUXBtfDanWaQTcSW2WEXh2lUgE041MMWQyATmZKy8gVdAl+V Xj2Y+4A8g2bQN+Q6T9J2s4E23yEF8H/VPT+WsjEL0IjMDiB2d0saBYK2BlMPe3XT L0C0ho+NpNqJ++5Zubr/54cEN7q3yA== =6Y8M -----END PGP SIGNATURE----- --=-=-=--