Re: [Cbor] Serialization choices vs. CDDL (Re: CDDL optionality and choices and optionality in CBOR and CDDL)

Carsten Bormann <cabo@tzi.org> Sat, 13 April 2024 07:54 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 22325C14CEFD for <cbor@ietfa.amsl.com>; Sat, 13 Apr 2024 00:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 nk-v5gi24Lne for <cbor@ietfa.amsl.com>; Sat, 13 Apr 2024 00:54:23 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.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 3436CC14F69D for <cbor@ietf.org>; Sat, 13 Apr 2024 00:54:21 -0700 (PDT)
Received: from smtpclient.apple (p5089a211.dip0.t-ipconnect.de [80.137.162.17]) (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 4VGm0p6C9TzDCbb; Sat, 13 Apr 2024 09:54:18 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAKoiRubmXLAYx9HvXF2P2SPKEudobSMoBHFDZURSgZ49bAym8g@mail.gmail.com>
Date: Sat, 13 Apr 2024 09:54:08 +0200
Cc: cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0661929F-C196-4612-86A6-E72D70ED71E1@tzi.org>
References: <CAKoiRubb4GMm1sTq_1XRZt3+-hy+Z8ZXD21DpK5voneXFRcW6A@mail.gmail.com> <AFF12C56-CB02-43C8-9EFA-5656CAEF9E9A@tzi.org> <CAKoiRubmXLAYx9HvXF2P2SPKEudobSMoBHFDZURSgZ49bAym8g@mail.gmail.com>
To: Rohan Mahy <rohan.mahy@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/e23iUUOvwHzFc5n75moDHg4o4Jc>
Subject: Re: [Cbor] Serialization choices vs. CDDL (Re: CDDL optionality and choices and optionality in CBOR and CDDL)
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: Sat, 13 Apr 2024 07:54:27 -0000

On 13. Apr 2024, at 08:42, Rohan Mahy <rohan.mahy@gmail.com> wrote:
> 
> Hi Carsten,
> 
> Asking for more clarification inline please.
> 
> On Fri, Apr 12, 2024, 22:55 Carsten Bormann <cabo@tzi.org> wrote:
>> On 13. Apr 2024, at 02:49, Rohan Mahy <rohan.mahy@gmail.com> wrote:
>> > 
>> > I interpret the CDDL spec to mean that the encoding of the first item in the array is either F6 (null);  or 58 20 followed by 32 octets. Did I interpret the CDDL spec correctly? 
>> 
>> CDDL operates on the data model level, not on the representation format level.
>> 
> sure. but if a tool is using a CDDL model to validate a CBOR instance document, does the CDDL model below mean "an array of two items, the first of which is either a null or a bstr, the second of which is a tstr"?

Yes.

> foo = [
>   item1 = null / bstr,
>   item2 = tstr
> ]

(With corrected syntax:)

> foo = [
>   item1: null / bstr,
>   item2: tstr
> ]

Let’s generate 10 example instances (using the cddl tool mentioned in [1]):

$ pbpaste | cddl - g 10
[h'7375636B656E6572', "Rudolphus"]
[h'636F616273756D65', "Cyanocitta"]
[null, "parol"]
[h'687964726F636172626F6E6963', "foretime"]
[null, "ocypodan"]
[h'756E64657273776561726572', "aliethmoidal"]
[h'6F76657268617374696E657373', "docility"]
[null, "uninstructing"]
[null, "superaccomplished"]
[h'6D6F6E6F63617270616C', "romancy"]

Looks good to me.

[1]: https://www.rfc-editor.org/rfc/rfc8610.html#appendix-F

> If so, it should validate an instance document whose first array item is a null, yes?

Indeed.

>> The .size control operator on an integer is a convenient way to limit the range of an integer based on what the maximum value for the minimum encoding size for that integer is, not the actual size in the representation format.
>> 
> It sounds like you are saying that I can't apply the .size operator to a byte string?

No, I just was specifically talking about applying it to an integer.
Clearly you can [2].
Maybe I misread your example.

[2]: https://www.rfc-editor.org/rfc/rfc8610.html#section-3.8.1

> (I was not asking about setting the size of an integer). I want a 32 octet byte string, not a 4 octet uint32.

foo = bstr .size 32

…indeed gives you that. 3 examples:

$ pbpaste | cddl - g 3
h'6A36785837BC3EA597546AF24605914F4D3605E207467345CB94424BFAA691AF'
h'9CC91458219CA20A05E4C0D71D95403DD0D5ADE460AA9C66194DBB9B9EAE5E3A'
h'5F797BAA5ED4720D53E58A6FC99D628DAEC81140430E24EDEE71923D0670F521'

(If you want, say, a byte size of 4 to 32 bytes, you can use:

bar = bstr .size (4..32)

3 examples:

$ pbpaste | cddl - g 3
h'4CD609A8F2141D02BE44F406C6CB4A5788F7C4F577A3'
h'81EEF48222C7919C18A529D2D0E7DC47163770E88DBA4C91487FB4275316DAD2'
h'5667626A7C6E44EA065C46813CD604EF59A63D'

)

Grüße, Carsten