Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

[Giridhar Mandyam <[e-mail]>]

I am not sure I understand what is being suggested in this email chain.  As far as I can tell (focusing on the CBOR option for EAT alone):


  1.  EAT inherits from CWT, and CWT’s are ultimately CBOR objects.
  2.  There is no prohibition against defining a CBOR array with CWT’s/EAT’s as entries, and those can be of indeterminate length – see https://datatracker.ietf.org/doc/html/rfc7049#section-2.2.1.
  3.  In addition, as per https://datatracker.ietf.org/doc/html/rfc7049#section-2.1 an array can contain entries from multiple data types.  An array could contain UCCS’s, EAT’s, and standard (RFC 7049-defined) CBOR data types for example.

Is the suggestion for the EAT document prohibit (or at least limit) the above?  If so, what would be the justification for such a limitation?

-Giri

From: RATS <[e-mail]> On Behalf Of Laurence Lundblade
Sent: Tuesday, May 31, 2022 9:54 AM
To: Thomas Fossati <[e-mail]>
Cc: Nancy Cam-Winget (ncamwing) <ncamwing=[e-mail]>; [e-mail]
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

I am definitely not a fan of unconstrained fan out here. Probably the right thing to do is require any additional token type be an IETF standard.

One reason I made these sockets is so that UCCS/UJCS will plug in and be part of a submod Nested-Token and part of a DEB. It is important that UCCS and UJCS be brought into EAT this way.

Personally, I think it would probably be good if this never went beyond UJCS/UCCS.

I’m still digesting Simon’s collection proposal…

Thanks for point that out, Thomas.

LL




On May 31, 2022, at 3:00 AM, Thomas Fossati <[e-mail]<mailto:[e-mail]>> wrote:

{Lemaître hat on}

"where does a EAT end?"

The CDDL has:

$$EAT-{CBOR,JSON}-{Unt,T}agged-Token /= ...

which says it is theoretically possible to extend a EAT to cover
anything, as long as it looks like a CBOR or JSON stream.

The EAT I-D defines the CWT, JWT and DEB types.

But UCCS will have to plug into the same CDDL socket soon.

And Simon's proposal to add the "EAT collection" type [1] uses the same
mechanism to extend the semantics of a EAT in the same direction as DEB
- i.e., by providing an aggregation primitive.

My observation is that unless the EAT I-D contains clear criteria for
scoping its type system its governance can become quite tricky down the
line.

cheers, thanks

[1] https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats