Re: [COSE] [Rats] Defining CWT, and JWT in UCCS in EAT

[Laurence Lundblade <[e-mail]>]

Generally agree with what you say below, Carsten.

It is partly my mistake for bringing up 8152bis. I didn’t realize 9051 and 9052 were out. I only brought it up because someone else suggested we put the CWT CDDL in a COSE document.

I believe there has been some confusion between these two:
   1) The CDDL for a CWT
   2) A new CDDL mechanism kinda like .cbor so that the CDDL for an encrypted COSE payload can be specified. There would be two parts to this
       2a) Some additional CDDL control add-on to RFC 8610 that is not COSE-specific
       2b) An add-on to the COSE spec that makes use of the new CDDL control for payload specification

To write a full tight CDDL spec for CWT, we need all off the above. 

But of course the prose-based specification of COSE and CWT are perfectly fine now; the above would just allow all of it to be expressed in CDDL, rather than partly in prose and partly in CDDL.

(Seems like we’re in a transition period into the CDDL era were we are going to have a number of RFCs that add some CDDL to an existing document that isn’t fully CDDL. Some of these will be because CDDL itself is evolving. Not a bad thing, but a transition nevertheless).

LL



> On Jan 4, 2022, at 8:09 AM, Carsten Bormann <[e-mail]> wrote:
> 
> On 2022-01-04, at 14:02, Jeremy O'Donoghue <[e-mail]> wrote:
>> 
>> I absolutely would not put the CWT CDDL into RFC8152bis – it is a payload definition, and RFC8152 is nicely agnostic as to payload right now – it makes sense to keep it that way.
> 
> Obviously.
> 
> But before I agree with you any further, please note that we are not at liberty to put new work into the two RFCs-to-be (9051 and 9052) that used to be called RFC8152bis.  These are approved documents, and they have long left the WG.
> 
>> I agree with Laurence that RFC8152bis needs a way to indicate the payload type.
> 
> I don’t understand this sentence, not only because RFC8152bis doesn’t really need anything (see above), but also because there is common header “content type” (label 3), which is a way to indicate the payload type.
> 
> Note that CWT is reasonably well-defined (suffering only by the lack of CDDL definitions for the individual registrations, and of a CDDL framework to put these in).  All we seem to be discussing is the editorial matter where to put a CDDL definition that expresses that content.  We are doing this not because we “need” it, but to make it easier to exercise the well-defined extension points CWT offers.
> 
> I’m not sure I understand the rest of the message given that background.
> There is no need for a CWTbis.  Any document could define that CDDL, even EAT. I’d still prefer to have this CDDL text and the accompanying conventions explained in a separate document.  (No, splitting that out doesn’t need to delay EAT.)  Which WG gets to run the process for agreeing that document is a second-order consideration; the decision should be dominated by quality and expediency considerations (including any rechartering that may be required).  There is no need to wait with writing that document while that decision is being made by the SEC ADs; we can simply discuss it by cross-posting to all candidate WGs.
> 
> As a general observation, the IETF is really bad in writing up small tweaks to an existing specification that may be needed for new work unless that happens in the same WG.  Another contributor to the appetite for large, long-running WGs...
> 
> Grüße, Carsten
> 
>