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