From: "Smith, Ned" <ned.smith@intel.com>
To: Thomas Fossati <thomas.fossati@linaro.org>
Thread-Topic: [Rats] When to use profile in media-type vs. as an EAT claim
Thread-Index: AQHbUWujb28F4Gu6c0ON1MT32iy7LrLsbckAgAFmem4=
Date: Thu, 19 Dec 2024 17:40:36 +0000
Message-ID: 
 <CO1PR11MB51691963CA5F31117BDD88AFE5062@CO1PR11MB5169.namprd11.prod.outlook.com>
References: 
 <CO1PR11MB516952D60311B55DD16A8B4EE5052@CO1PR11MB5169.namprd11.prod.outlook.com>
 <CA+1=6yfd0_h5ySqXCNgz=GmgwFqmQXDuow=T=MFCg1R7P2SkDw@mail.gmail.com>
In-Reply-To: 
 <CA+1=6yfd0_h5ySqXCNgz=GmgwFqmQXDuow=T=MFCg1R7P2SkDw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?Windows-1252?Q?NE9xzY2V/3vPzrAPqxfVKlb6dH1/W4aZIQeT2aD0Cj6HcWiyy7TNSsOO?=
 =?Windows-1252?Q?usoAqXtlBcC/Ywz8r4C3OBTOuqGWk4mk9bc8hQ7EjNAPHHS2ENXrHa5B?=
 =?Windows-1252?Q?jVWFfWn0vi+lgI4kQZGJpBwYtxIbmktGR97ua0LkmLrNxhhvh6MUHC6M?=
 =?Windows-1252?Q?lPn6dgsEOYiS3Vi/rXxHSCJf9PtO5Q1122UNNzrMsZyjgwdFmvXGON6B?=
 =?Windows-1252?Q?Hvf630gr00X+njX6HFH/NuzAfUrI+7DnBGUHPExSS71FI4IqPKYb8HCC?=
 =?Windows-1252?Q?VRQW/37Hgbivl2DYoEyOYyBc1z0+SEj6Cf+jF1UwUuNBrOQ7BFtZWIo0?=
 =?Windows-1252?Q?g7JBSruyczsxLaqPUPD9UOnpVzC9AvkVO19eJF4ZPkomh8CF0JpyHP3I?=
 =?Windows-1252?Q?qvWXWKsCO5IuGUkk0r2WYHGfJUFTZT6+kZQtRf2d3tVn/nwdGxpwtZ4O?=
 =?Windows-1252?Q?gCDZlADrbBNEfmM0TAkEWg2Tb+DXs68ElglUzRUTgEeRWOgzRMjoNDC5?=
 =?Windows-1252?Q?b7ZAYEs/AWAdagNDa8jqoxP2rgUHgnG1Ey3jcvNuscohXU3GFZMrKo3T?=
 =?Windows-1252?Q?2Mt34UXfqQilLyJjIHSNLB+N2OQlz+SC2Xcr95ZAFUndSZTttxjDiTdn?=
 =?Windows-1252?Q?OAFSD+HbwqQqP+ku1EWXHjTtal2maoit84+2c/YnAaMBHqzbJCxObgVT?=
 =?Windows-1252?Q?LGztptscY7wXKDCAJZwudseyVTZh/vK16IgmYxQ1BiIPZ1SsXQDq1n4X?=
 =?Windows-1252?Q?9pMt1Wusa4L1fmM+tYSLCPMH0tnTPzSuQcbU24JPcSy7S5kI46A79+qF?=
 =?Windows-1252?Q?K9HYEbM/aW1ORLCyqLuyOJ6aClv6d1GLGpf5AapKbQ4rpE6CLs4T0uth?=
 =?Windows-1252?Q?GPfy1V5VSTvQXn77oH0q9Jaj3erb7ColbnAeAo0Ou9FLRiql2//mKcNE?=
 =?Windows-1252?Q?2Rgz/CYFZUP8xw6gbREuW5S/03cwQzTk6ZtbGpaTA0V4wLbuiP0KYE5x?=
 =?Windows-1252?Q?ZbSw+L8FBL7d+Izm4Jc8MyprgS5F/2PfKfmPQCoKIEwELc6rU6NmHa90?=
 =?Windows-1252?Q?S6gRt7FQ0YB+IZWKQjVI27q6g+SM9kb1/SOdFookyIRp9D37UHFnze9E?=
 =?Windows-1252?Q?YRo5v+s4A1h7tSw7DHpZbpjsXeXQspLdQKYFw8p3ygHtOoG6crrw/CoU?=
 =?Windows-1252?Q?65Oj9ndfkqf0bK8BaCM21mmXhczciKNIxhlyJFxy7zCy7yZy7L/HaSYL?=
 =?Windows-1252?Q?I5e4M6fT7zPdyDM+CQ0Z2AWP78/poREGSRPQ0n9TuM2ovEa89xjUeJX4?=
 =?Windows-1252?Q?zmeMENi/qyXyuiZyhLyK22FRXaiA8cZyXRgJZ10CpADuxncLgF7kmCrv?=
 =?Windows-1252?Q?KvK4HrTavgicc4EgtfYd7TptYqU93ZUFQKasHMY4otfxolL8Gm5CwazQ?=
 =?Windows-1252?Q?zSjFuOm0ujWmvfP5Itmp4pwvhgmDuVo+4CnI/FtbhAv1DDRIfIF6MWv1?=
 =?Windows-1252?Q?AufcOQKGttyuE0TdaaYyHn4iFdxHtYfVNlqkJglIIhJy2X2f+KTqN4Sj?=
 =?Windows-1252?Q?B7/cYJaAOVrJDlKI2GrMnhyLLKh/JF2biANVM4BYYxOsF4SBMBHqCWB5?=
 =?Windows-1252?Q?+V/hFhalAxHWOFoO10k8DALrPWDeCdj+Dq+lQHafYVCnnkSibAjUVI4c?=
 =?Windows-1252?Q?BfRXJkETXnNZn7DwRvRUjvMMM5xOjjm2qVrZG7iwWcIeBwmnk2z2Og?=
 =?Windows-1252?Q?=3D=3D?=
Content-Type: multipart/alternative;
	boundary="_000_CO1PR11MB51691963CA5F31117BDD88AFE5062CO1PR11MB5169namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 1b48d69d-a8f7-42e4-2913-08dd20543f20
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2024 17:40:36.4755
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 5xc6oy+vnEpNIxb0ZdUGsjp8Wh+xhQQ2axA+JL4R9kLvULkwNftwJ3uE9/saqQlH6jZPeDW4R2lwSDir3kPKtA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7672
X-OriginatorOrg: intel.com
Message-ID-Hash: C5RQPAN7J3S6NTDV4UPRB26FJBJE4LTO
X-Message-ID-Hash: C5RQPAN7J3S6NTDV4UPRB26FJBJE4LTO
X-MailFrom: ned.smith@intel.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-rats.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: "rats@ietf.org" <rats@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_When_to_use_profile_in_media-type_vs=2E_as_an_EAT?=
	=?utf-8?q?_claim?=
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/rOONTWPGTPmhhOTmZia-r4iqvys>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

--_000_CO1PR11MB51691963CA5F31117BDD88AFE5062CO1PR11MB5169namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

> To be clear, we are talking about an EAT- and CoRIM-based Measurements fo=
rmats, correct?
That=92s my mental context, but in theory, any media-type / C-F could appea=
r in the EAT.Measurements or a CMW.cbor-record. Some may include profile in=
formation, but some won=92t. If not, then you must look to other sources li=
ke 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 st=
ages) 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 t=
hough the data model describes them as such).

My concern is that the parser architecture isn=92t defined anywhere, so the=
re is no concrete way to determine whether the profile semantics we are dis=
cussing are correct.
-Ned

From: Thomas Fossati <thomas.fossati@linaro.org>
Date: Wednesday, December 18, 2024 at 12:06
To: Smith, Ned <ned.smith@intel.com>
Cc: rats@ietf.org <rats@ietf.org>
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 <ned.smith@intel.com> wrote:
> The EAT draft defines a profile claim that qualifies various aspects of w=
hat a parser might expect to have to parse in terms of which claims and oth=
er 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 ind=
icate 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 p=
rofile value (I think).

Yes.

> If so, then there is the possibility that the Content-format value in Mea=
surements 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 popu=
lated, but the content-format doesn=92t 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 c=
laim 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

--_000_CO1PR11MB51691963CA5F31117BDD88AFE5062CO1PR11MB5169namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Aptos;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:12.0pt;
	font-family:"Aptos",sans-serif;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	mso-ligatures:none;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style>
</head>
<body lang=3D"EN-US" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">&gt;</span><span st=
yle=3D"font-size:11.0pt"> To be clear, we are talking about an EAT- and CoR=
IM-based Measurements formats, correct?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">That=92s my mental =
context, but in theory, any media-type / C-F could appear in the EAT.Measur=
ements or a CMW.cbor-record. Some may include profile information, but some=
 won=92t. If not, then you must look to
 other sources like EAT.profile or CoRIM.profile. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">But if parser archi=
tecture 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).
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">My concern is that =
the parser architecture isn=92t defined anywhere, so there is no concrete w=
ay to determine whether the profile semantics we are discussing are correct=
.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">-Ned</span><span st=
yle=3D"font-size:11.0pt"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<div id=3D"mail-editor-reference-message-container">
<div>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=
or:black">From:
</span></b><span style=3D"color:black">Thomas Fossati &lt;thomas.fossati@li=
naro.org&gt;<br>
<b>Date: </b>Wednesday, December 18, 2024 at 12:06<br>
<b>To: </b>Smith, Ned &lt;ned.smith@intel.com&gt;<br>
<b>Cc: </b>rats@ietf.org &lt;rats@ietf.org&gt;<br>
<b>Subject: </b>Re: [Rats] When to use profile in media-type vs. as an EAT =
claim<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">Hi Ned,<br>
<br>
On Wed, 18 Dec 2024 at 17:51, Smith, Ned &lt;ned.smith@intel.com&gt; wrote:=
<br>
&gt; The EAT draft defines a profile claim that qualifies various aspects o=
f what a parser might expect to have to parse in terms of which claims and =
other restrictions/additions to enveloped payloads.<br>
&gt;<br>
&gt; The CMW draft anticipates there will be media types that include profi=
le information as an optional parameter to the media type definition.<br>
&gt;<br>
&gt; The EAT Measurements claim relies on a content-format (media type) to =
indicate what content follows in the Measurements payload.<br>
&gt;<br>
&gt; If a media type with profile is defined,<br>
<br>
To be clear, we are talking about an EAT- and CoRIM-based Measurements<br>
formats, correct?<br>
<br>
&gt; then the content-format/content-ID value will be different based on th=
e profile value (I think).<br>
<br>
Yes.<br>
<br>
&gt; If so, then there is the possibility that the Content-format value in =
Measurements claim will already include profile information.<br>
&gt;<br>
&gt; Hence, inclusion of the profile claim seems redundant.<br>
<br>
Not really, the EAT Measurement claim is very similar to type&amp;value<br>
CMWs, where the outer type is used to dispatch the raw value to the<br>
handler.&nbsp; The higher the typing precision, the more efficient the<br>
routing.&nbsp; If the dispatch is coarse-grained, the handler must do two<b=
r>
passes: one to extract the profile, and another to parse the payload<br>
accordingly.<br>
<br>
&gt; My question is what is the expected behavior if the profile claim is p=
opulated, but the content-format doesn=92t use a profile specific form?<br>
<br>
The parser does two passes over the measurement claim.<br>
<br>
&gt; Will parsers be expected to process this the same way as if the profil=
e claim was omitted and the profile specific content-format form is used?<b=
r>
<br>
I believe the parser only does a single pass in this case.<br>
<br>
cheers, t<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_CO1PR11MB51691963CA5F31117BDD88AFE5062CO1PR11MB5169namp_--