Re: [Ace] Embedded Content Types

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

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"

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. 


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