> 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 <i...@augustcellars.com> Sent: Thursday, February 21, 2019 4:54 PM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; 'Carsten Bormann' <c...@tzi.org> Cc: ace@ietf.org; 'Klaus Hartke' <har...@projectcool.de>; draft-ietf-ace-coap-...@ietf.org Subject: RE: [Ace] Embedded Content Types > -----Original Message----- > From: Panos Kampanakis (pkampana) <pkamp...@cisco.com> > Sent: Thursday, February 21, 2019 1:32 PM > To: Carsten Bormann <c...@tzi.org> > Cc: Jim Schaad <i...@augustcellars.com>; ace@ietf.org; Klaus Hartke > <har...@projectcool.de>; draft-ietf-ace-coap-...@ietf.org > 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 <c...@tzi.org> > Sent: Wednesday, February 20, 2019 8:11 PM > To: Panos Kampanakis (pkampana) <pkamp...@cisco.com> > Cc: Jim Schaad <i...@augustcellars.com>; ace@ietf.org; Klaus Hartke > <har...@projectcool.de>; draft-ietf-ace-coap-...@ietf.org > Subject: Re: [Ace] Embedded Content Types > > On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) > <pkamp...@cisco.com> 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
