Re: [Cbor] CDDL and b64u for JSON and byte array for CBOR

Carsten Bormann <cabo@tzi.org> Thu, 25 January 2024 13:29 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66CEC151701 for <cbor@ietfa.amsl.com>; Thu, 25 Jan 2024 05:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60rVqd94AA0d for <cbor@ietfa.amsl.com>; Thu, 25 Jan 2024 05:29:40 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F151BC14F697 for <cbor@ietf.org>; Thu, 25 Jan 2024 05:29:39 -0800 (PST)
Received: from eduroam-0298.wlan.uni-bremen.de (eduroam-0298.wlan.uni-bremen.de [134.102.17.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4TLMB90x0GzDClQ; Thu, 25 Jan 2024 14:29:37 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <ME3P282MB1347A5F2577BB44F8DA14C2BF07B2@ME3P282MB1347.AUSP282.PROD.OUTLOOK.COM>
Date: Thu, 25 Jan 2024 14:29:36 +0100
Cc: "cbor@ietf.org" <cbor@ietf.org>
X-Mao-Original-Outgoing-Id: 727882176.547618-a23b3b97bd29a7e23021be2b34909854
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDE67E86-4CEF-4433-942E-2CB065C52054@tzi.org>
References: <ME3P282MB1347A5F2577BB44F8DA14C2BF07B2@ME3P282MB1347.AUSP282.PROD.OUTLOOK.COM>
To: Oliver Terbu <oliver.terbu=40mattr.global@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/VYohMxlyCFeux5lSh4dY_llpzFU>
Subject: Re: [Cbor] CDDL and b64u for JSON and byte array for CBOR
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2024 13:29:44 -0000

Hi Oliver,

> On 2024-01-24, at 21:14, Oliver Terbu <oliver.terbu=40mattr.global@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> I have a CDDL for a data model with potential serialization to JSON/CBOR and I have map entry that could be either a byte array or a base64url-encoded text representation of the byte array. 
> 
> Some = {
>   "key": #6.21(bstr)
> }
> 
> Does the CDDL above express that correctly?

The CDDL expresses that the value under “key” needs to be a tag 21 on a byte string.  It does not directly allow the base64url-encoded text representation that JSON would need.

The purpose of the tag 21 would be to "indicate that a byte string might require a specific encoding when interoperating with a text-based representation” (Section 3.4.5.2 of RFC 8949 [1]).

[1]: https://www.rfc-editor.org/rfc/rfc8949.html#name-expected-later-encoding-for

It goes on to say:

  "These tags are useful when an encoder knows that the
   byte string data it is writing is likely to be later converted to a
   particular JSON-based usage.”

So the assumption here is that a processor that converts the CBOR to JSON can do this without knowing the CDDL data description, based on the mere presence of the tag 21.

If you can assume that the processor will be aware of the data definition, you can put a description both for a CBOR representation and a JSON representation into a single piece of CDDL, e.g., by using

  JC<J,C> = J .feature "json" / C .feature "cbor"

from RFC 9165, combined with .b64u from draft-ietf-cddl-cbor-more-control:

  binary = JC<text .b64u bstr, bstr>

or, more generally:

  binary-data<D> = JC<text .b64u D, D>

so you can be more specific what those data D is.
By relying on the processor’s awareness of the data definition, you save one byte that is needed for actually encoding tag 21 otherwise.

Examples that the CDDL tool generates for JSON and CBOR, respectively, are shown below.

Grüße, Carsten

$ cat jc.cddl
binary = JC<text .b64u bstr, bstr>
JC<J,C> = J .feature "json" / C .feature “cbor"

$ CDDL_FEATURE_OK=cbor,^json cddl jc.cddl gp 10
/binary/ h'717569766572697368'
/binary/ h'656E646F7374796C6172'
/binary/ h'6D616C6C6F736569736D6963'
/binary/ h'73757065726571756976616C656E74'
/binary/ h'706F726B776F6F64'
/binary/ h'44696374796F736970686F6E'
/binary/ h'4672616E636F6E69616E'
/binary/ h'73636C65726F7469636F63686F72696F696469746973'
/binary/ h'6174696C74'
/binary/ h’657061676F676963'

$ CDDL_FEATURE_OK=json,^cbor cddl jc.cddl gp 10
/binary/ "c25haWw"
/binary/ "VGV0cmFkeW5hbWlh"
/binary/ "aW50ZXJmZXJl"
/binary/ "cHJlY2F2YWw"
/binary/ "Y291bnRlcnN0YXRhbnQ"
/binary/ "ZW1lcmdlbmN5"
/binary/ "c2xlZXBlcmVk"
/binary/ "aG9ybndvcnQ"
/binary/ "cGhhcm1hY29tZXRlcg"
/binary/ “c3VwcmFzcGluYXRl"