Re: [Ace] Embedded Content Types

["Panos Kampanakis (pkampana)" <[e-mail]>]

> This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".

Not sure I am following. Are these two request URIs? Or in the discovery response?


-----Original Message-----
From: Jim Schaad <[e-mail]> 
Sent: Thursday, February 21, 2019 4:54 PM
To: Panos Kampanakis (pkampana) <[e-mail]>; 'Carsten Bormann' <[e-mail]>
Cc: [e-mail]; 'Klaus Hartke' <[e-mail]>; [e-mail]
Subject: RE: [Ace] Embedded Content Types



> -----Original Message-----
> From: Panos Kampanakis (pkampana) <[e-mail]>
> Sent: Thursday, February 21, 2019 1:32 PM
> To: Carsten Bormann <[e-mail]>
> Cc: Jim Schaad <[e-mail]>; [e-mail]; Klaus Hartke 
> <[e-mail]>; [e-mail]
> Subject: RE: [Ace] Embedded Content Types
> 
> Thanks Carsten.
> 
> Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a 
> different URI imo, so it changes the EST spec and that introduces 
> changes that affect CAs that already implemented it. So let's say we do /skg?sk=xxx&spk=yyy.
> When I am doing resource discovery and the server is returning the 
> content formats for skg, is he going to signal his supported formats 
> with
> </est/skg>;rt="ace.est.skg";ct="62 xxx yyy"

This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".  This does not change any existing servers other than getting the ct values corrected in discovery.


> 
> RFC5272 says
> > The Content-Format code "ct" attribute provides a hint about the 
> > Content-Formats this resource returns.  Note that this is only a 
> > hint, and it does not override the Content-Format Option of a CoAP 
> > response obtained by actually requesting the representation of the resource.
> > [...] The Content-Format code attribute MAY include a 
> > space-separated sequence of Content-Format codes, indicating that 
> > multiple content-formats are available.
> 
> So it looks tome that ct="62 280 284 281 TBD287" could hint to the 
> client that all the following formats are supported for the multipart.
> 
> I had a chat with Klaus where he mentioned that he assumed the ct="63 
> xxx yyy" returned attribute values are the accepted values by the 
> server in the "Accept" option.

I would agree with Klaus that this is a correct answer.

Jim

> 
> 
> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Wednesday, February 20, 2019 8:11 PM
> To: Panos Kampanakis (pkampana) <[e-mail]>
> Cc: Jim Schaad <[e-mail]>; [e-mail]; Klaus Hartke 
> <[e-mail]>; [e-mail]
> Subject: Re: [Ace] Embedded Content Types
> 
> On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) 
> <[e-mail]> wrote:
> >
> > If we broke the requests to different URIs, it means that a client 
> > needs to
> keep track of his transactions and on top of it he needs to correlate 
> the key and the cert he receives at a later time.
> 
> I think this is just a misunderstanding — the idea wasn’t to supply 
> the parts under different URIs, but to make up different URIs for 
> retrieving the different combinations coming in one multipart-core, in one transaction.
> 
> As in
> 
> /skg?sk=284&spk=281
> 
> (Where sk is short for “secret key” and spk for “signed public key” — 
> substitute your own names.)
> 
> or, say
> 
> /skg/284,281
> 
> This provides full format agility while preserving the interaction model.
> 
> Grüße, Carsten