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