Re: [Ace] Embedded Content Types

[Jim Schaad <[e-mail]>]

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