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

[Thomas Fossati <[e-mail]>]

> Thomas is asking whether we really do want this open ended the way use of a socket implies. I think it is a good question. I think the answer is yes, but in severely limited way — that socket may only be fulfilled by things that are an IETF standard. I think it is a one line addition to EAT.

Thanks Laurence.  Do we need a registry as well?


From: RATS <[e-mail]> on behalf of Laurence Lundblade <[e-mail]>
Date: Wednesday, 1 June 2022 at 00:17
To: Smith, Ned <[e-mail]>
Cc: Giridhar Mandyam <[e-mail]>, Thomas Fossati <[e-mail]>, [e-mail] <[e-mail]>, Nancy Cam-Winget (ncamwing) <ncamwing=[e-mail]>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
A *socket* is a specific way of calling out an extension point in CDDL. When you say something is a CDDL socket you are saying that other documents and drafts can extend it. You know something in CDDL is a socket when it starts with $$ or $.

For example $$Claims-Set-Claims is a socket because we really do want people to define lots of claims outside the EAT document.

The top-level message in EAT is a CDDL socket:

    EAT-CBOR-Token = $$EAT-CBOR-Tagged-Token / $$EAT-CBOR-Untagged-Token
    EAT-JSON-Token = $$EAT-JSON-Token-Formats

This is signaling that there can be other documents and drafts  that define further top level EAT messages beyond CWT, JWT and DEB.

I made the top-level EAT message a socket to deal with UCCS and UJCS being in a separate lagging document.

Thomas is asking whether we really do want this open ended the way use of a socket implies. I think it is a good question. I think the answer is yes, but in severely limited way — that socket may only be fulfilled by things that are an IETF standard. I think it is a one line addition to EAT.

LL



On May 31, 2022, at 1:56 PM, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

+1 “I am not sure I understand what is being suggested in this email chain”

Data definition languages and encoding schemes are flexible / extensible by design. I don’t think anyone is saying we should change this (correct me if I’m wrong).

When modeling a device / system object, the object being modeled has inherent structure that limits the need for arbitrary expressiveness and extension. Hence, the object (or a schema for the object) should be the oracle that resolves questions about “where EAT ends”.

If the concern is that due to a lack of oracles, arbitrary flexibility should be incorporated in the EAT draft, then some guard rails should be in place. For example, observing where structures can be extended later (vs. defining flexible but nebulous structures or making something optional that in practice is unused).

Are there structures in the draft that should be characterized as nebulous?

Thanks,
-Ned

From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, May 31, 2022 at 12:55 PM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing=[e-mail]<mailto:ncamwing=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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 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):


a.       EAT inherits from CWT, and CWT’s are ultimately CBOR objects.

b.       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.

c.       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]<mailto:[e-mail]>> On Behalf Of Laurence Lundblade
Sent: Tuesday, May 31, 2022 9:54 AM
To: Thomas Fossati <[e-mail]<mailto:[e-mail]>>
Cc: Nancy Cam-Winget (ncamwing) <ncamwing=[e-mail]<mailto:ncamwing=[e-mail]>>; [e-mail]<mailto:[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

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.