[Lake] Re: [EXT] Re: CDDL in EDHOC RFC 9528

["Sipos, Brian J." <[e-mail]>]

Carsten,
For the second typo, I mean simply that the current definition looks like the following, which fails to comply with CDDL syntax.

PLAINTEXT_2 = (
  C_R,
  ID_CRED_R : map / bstr / -24..23,
  Signature_or_MAC_2 : bstr,
  ? EAD_2,
)

While it should have a type applied to `C_R` that is consistent with the text (and with the definition of `message_1` rule) like the following.

PLAINTEXT_2 = (
  C_R : bstr / -24..23,
  ID_CRED_R : map / bstr / -24..23,
  Signature_or_MAC_2 : bstr,
  ? EAD_2,
)

> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Wednesday, October 16, 2024 9:29 AM
> To: Sipos, Brian J. <[e-mail]>
> Cc: [e-mail]
> Subject: [EXT] Re: [Lake] CDDL in EDHOC RFC 9528
> 
> APL external email warning: Verify sender [e-mail] before clicking links or
> attachments
> 
> Hi Brian,
> 
> thank you for looking into this.
> Whatever comes out of this I would like to reflect in
> 
> https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-04.html
> 
> (And the accompanying library of referenceable CDDL specifications in the cddlc
> tool.)
> 
> On 2024-10-16, at 14:41, Sipos, Brian J. <[e-mail]> wrote:
> > […]
> >    EAD_1 = (1* ead)
> 
> Right.  Actually, this should be a + instead of a 1*, + is much more idiomatic in
> CDDL.
> 
> > Another is the lack of a type within the `PLAINTEXT_2` group for the field `C_R`
> which just seems like a simple omission.
> 
> I’m not entirely sure I understand these CDDL snippets, e.g., ID_CRED_I also isn’t
> defined as a type.
> 
> > Finally, there is the use of a type `map` within the ID_CRED_x fields, which is
> not actually defined anywhere for CDDL. So I added a local definition
> >     map = #5
> > I’m not sure if that is the best way to handle this situation. Another alternative
> would be something more CDDL-like
> >     { * any => any }
> 
> If this is what you want, I’d prefer that a lot over #5.
> But maybe it actually isn’t *any* map?
> 
> BTW, map is not a predefined name so you can say
> 
> map = { * any => any }
> 
> if you like...
> 
> > I don’t think the two differ in what they will match but maybe the second form
> is more tool-friendly?
> 
> The original cddl tool can be very specific in its taste, so you’ll get
> 
>   Can't generate prim 5 (RuntimeError)
> 
> for   map = #5
> 
> > As a suggestion for readability, I also think it’s helpful to have a couple of
> shared-type rules to make it obvious where different fields really do share the
> same type. One for connection IDs (shared between `C_I` and `C_R`) and one for
> credential IDs (shared between `ID_CRED_I` and `ID_CRED_R`) as the following
> >     id_conn = bstr / -24..23
> >     id_cred = map / bstr / -24..23
> 
> Very good idea.
> We could include CDDL that has been combed through a bit in the above I-D.
> 
> Grüße, Carsten
> 
> >
> > Thanks for any feedback,
> > Brian S.
> >
> > [1] https://www.rfc-editor.org/rfc/rfc9528.html#appendix-C.2
> > [2] https://crates.io/crates/cddl
> > [3] https://rubygems.org/gems/cddl
> >
> > --
> > Lake mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]