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

I believe the question is solely about extensibility of the top-level EAT formats via a CDDL socket. I believe this PR <https://github.com/ietf-rats-wg/eat/pull/194> can resolve the issue fully.

The only anticipated extension to plug into this socket is UCCS and UJCS. I see no need for a registry because only one pair is anticipated.

Listing it out fully, the top-level formats for and EAT are now:
    CWT
    JWT
    DEB (both CBOR and JSON) versions

This will be extended to two more:
   UCCS
   UJCS

Not everything that is extensible needs a registry. 

Or this — registries are about identifiers for things. The identifier space here is media types (MIME and CoAP) and/or CBOR tags. We already have a registry for these and definition of types and tags for the top-level types for these too.

I think profiles are mostly orthogonal here. They apply to what ever formats are allowed / defined, but they don’t control who or how these formats are defined. (And I don’t think we need a registry for profiles).

There’s some discussion in this thread about general extensibility of protocols. I don’t think EAT is much different than most other protocols in this regard. Is JWT nebulous? Is it wrong that we turned CWT into EAT? 

LL

> On Jun 2, 2022, at 9:35 AM, Smith, Ned <ned.smith@intel.com> wrote:
> 
> >the profile definition addresses interop
> Section 7 suggests that a profile can take on many forms. The EAT draft accommodates this by offering a way to reference the profile document (or whatever it happens to be). I interpret Thomas’s point that “the claims-set is governed by the CWT Claims registry, whilst the EAT type system has no
> such mechanism (yet)” to mean there isn’t a profile yet defined that operates like a global registry.
>  
> It seems IANA is being used as the global registry for code point names/values currently. IANA CBOR registry could be used for CBOR top level EAT structures, but such equivalent exists for JSON structures. 
>  
> However, it seems some EAT CBOR structures that could be considered ‘top level’ don’t currently have IANA CBOR registry entries.
>  
> Is the way forward for EAT draft to create IANA CBOR tags for top level EAT structures?
>  
> Thx,
> Ned
>  
> From: RATS <rats-bounces@ietf.org> on behalf of Giridhar Mandyam <mandyam@qti.qualcomm.com>
> Date: Thursday, June 2, 2022 at 6:20 AM
> To: Thomas Fossati <Thomas.Fossati@arm.com>, "rats@ietf.org" <rats@ietf.org>
> Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
>  
> >> I think the underlying data structures make it extensible, independent of the CDDL notation.  However if an implementor chooses to extend EAT without an accompanying standard as a result, then interoperability may not be assured.  Therefore it is in an implementor’s interest to define a standard if they are seeking interop.
>  
> >The core difference is the extensibility story for the claims-set is governed by the CWT Claims registry, whilst the EAT type system has no such mechanism (yet).
>  
> I don’t agree:  the profile definition addresses interop – see https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-7 <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-7>.  Up to this point, no-one has objected to the way profiles are defined in the specification, nor the lack of a registry.
>  
> -Giri
>  
> From: Thomas Fossati <Thomas.Fossati@arm.com> 
> Sent: Thursday, June 2, 2022 6:13 AM
> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; rats@ietf.org
> Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
>  
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> 
> > Giridhar Mandyam <mandyam@qti.qualcomm.com <mailto:mandyam@qti.qualcomm.com>> wrote:
> > I think the underlying data structures make it extensible, independent
> > of the CDDL notation.  However if an implementor chooses to extend EAT
> > without an accompanying standard as a result, then interoperability
> > may not be assured.  Therefore it is in an implementor’s interest to
> > define a standard if they are seeking interop.
>  
> The core difference is the extensibility story for the claims-set is
> governed by the CWT Claims registry, whilst the EAT type system has no
> such mechanism (yet).
>  
>  
>  
>  
> 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
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats