[Rats] Re: When to use profile in media-type vs. as an EAT claim

["Smith, Ned" <[e-mail]>]

> To be clear, we are talking about an EAT- and CoRIM-based Measurements formats, correct?
That’s my mental context, but in theory, any media-type / C-F could appear in the EAT.Measurements or a CMW.cbor-record. Some may include profile information, but some won’t. If not, then you must look to other sources like EAT.profile or CoRIM.profile.

But if parser architecture REQUIRES profile information in different stages (and the different sources of profile information feed different parser stages) then it seems the optionality of profiles whether as an extension to a media-type or as an EAT claim or a RIM statement are not optional (even though the data model describes them as such).

My concern is that the parser architecture isn’t defined anywhere, so there is no concrete way to determine whether the profile semantics we are discussing are correct.
-Ned

From: Thomas Fossati <[e-mail]>
Date: Wednesday, December 18, 2024 at 12:06
To: Smith, Ned <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Rats] When to use profile in media-type vs. as an EAT claim
Hi Ned,

On Wed, 18 Dec 2024 at 17:51, Smith, Ned <[e-mail]> wrote:
> The EAT draft defines a profile claim that qualifies various aspects of what a parser might expect to have to parse in terms of which claims and other restrictions/additions to enveloped payloads.
>
> The CMW draft anticipates there will be media types that include profile information as an optional parameter to the media type definition.
>
> The EAT Measurements claim relies on a content-format (media type) to indicate what content follows in the Measurements payload.
>
> If a media type with profile is defined,

To be clear, we are talking about an EAT- and CoRIM-based Measurements
formats, correct?

> then the content-format/content-ID value will be different based on the profile value (I think).

Yes.

> If so, then there is the possibility that the Content-format value in Measurements claim will already include profile information.
>
> Hence, inclusion of the profile claim seems redundant.

Not really, the EAT Measurement claim is very similar to type&value
CMWs, where the outer type is used to dispatch the raw value to the
handler.  The higher the typing precision, the more efficient the
routing.  If the dispatch is coarse-grained, the handler must do two
passes: one to extract the profile, and another to parse the payload
accordingly.

> My question is what is the expected behavior if the profile claim is populated, but the content-format doesn’t use a profile specific form?

The parser does two passes over the measurement claim.

> Will parsers be expected to process this the same way as if the profile claim was omitted and the profile specific content-format form is used?

I believe the parser only does a single pass in this case.

cheers, t