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 <c...@tzi.org> wrote:
>
> On 2022-01-04, at 14:02, Jeremy O'Donoghue <jodon...@qti.qualcomm.com> 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
>
>
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
