> 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 <[email protected]> Sent: Thursday, February 21, 2019 4:54 PM To: Panos Kampanakis (pkampana) <[email protected]>; 'Carsten Bormann' <[email protected]> Cc: [email protected]; 'Klaus Hartke' <[email protected]>; [email protected] Subject: RE: [Ace] Embedded Content Types > -----Original Message----- > From: Panos Kampanakis (pkampana) <[email protected]> > Sent: Thursday, February 21, 2019 1:32 PM > To: Carsten Bormann <[email protected]> > Cc: Jim Schaad <[email protected]>; [email protected]; Klaus Hartke > <[email protected]>; [email protected] > 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 <[email protected]> > Sent: Wednesday, February 20, 2019 8:11 PM > To: Panos Kampanakis (pkampana) <[email protected]> > Cc: Jim Schaad <[email protected]>; [email protected]; Klaus Hartke > <[email protected]>; [email protected] > Subject: Re: [Ace] Embedded Content Types > > On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) > <[email protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
