Re: [Cbor] CDDL spec should specify how CBOR items match types

I just noticed that the current draft is informational, so it can't be
used the way ABNF is used, to help with writing other standards, as
much as I'd like to. For informational documents, I agree that "pretty
clear" is enough, but I hope we can aim for a standard instead.

Jeffrey

On Thu, Jul 6, 2017 at 11:44 PM, Carsten Bormann <cabo@tzi.org> wrote:
> Hi Jeffrey,
>
> Yes, we have to replace “self-evident” etc. by actually explaining things.
>
> However, I’m pretty sure we are on the safe side with the # constructs, as well as with [] and {}.
> These may not be explained in so many words, but it is still pretty clear what they mean.
>
> We have more of an undefined state with literals such as 10, 10.0, 1e1, and with applying range operators, in particular if they span CBOR major types (-5..10 is pretty clear, but what does 1..10.0 mean?).  When applied to floating point, the range operator also does not say what precision is needed (you can help yourself with construct such as `-10.0..10.0 .and float16`, but that is neither supported by the tool nor explained at all).
>
> I would like to keep CDDL operating at the data model level, even with its history of toying with anchoring it at the serialization level.  Yes, the # construct is in serialization terms, but this is just a shortcut to have a single construct cover all of CBOR (well, you have to add {} and [], because these need groups).
>
> There are a few more areas that are not fully defined, e.g., which exact PCRE variant exactly does .regexp use.
> I would be inclined in *not* overspecifying this at this point.  (And we haven’t solved the “line too long” problem there; see prelude for tdate which is not using a regexp even though it could — try a `cddl -<<<x=tdate generate` for fun.)
>
> So, lots of editorial work remaining indeed, but the technical discussion probably should focus on the numeric system underlying CDDL.
>
> Grüße, Carsten
>
>
>> On Jul 7, 2017, at 01:01, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
>>
>> Apologies if I'm just reading
>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11
>> badly, but I don't see a specification of which CBOR items match which
>> types.
>>
>> Sections like https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11#section-3.4
>> (Arrays) specify how to write an array type, but I don't see a
>> normative statement that '82 01 02' is an instance of [*uint] or that
>> '01' and '42 01 02' aren't.
>>
>> I also don't see a definition of '#' in order to ground the meaning of
>> the prelude. "How this is used should be evident from the prelude
>> (Appendix E)." from 2.2.3. Representation Types isn't really
>> sufficient to specify it.
>>
>> I think this lack of specification is at the root of Kevin Braun's set
>> of bugs in https://mailarchive.ietf.org/arch/msg/cbor/Z1XcZSTLbTDnqA9HP8UXjeUOspE.
>>
>> I'd be inclined to fix this by specifying each CDDL type as a
>> recursive parser, which accepts or rejects either CBOR items or byte
>> strings. I think the choice of item vs bytes comes down to where we
>> want to put the serialization constraints (like
>> "indefinite-containers") described in
>> https://mailarchive.ietf.org/arch/msg/cbor/Pv191TJRBiG1QOJbJL8iVHjUDuE,
>> but it could also have some implications for how parsers return data
>> from unfinished byte streams.
>>
>> Jeffrey
>>
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
>>
>