> It seems a totally adhoc way that totally subverts the content-type system.
> It really seems like we need to take this to CORE.
Well it's the definition of the multipart-ct that causes the subversion of the
content-type system! CoAP as a protocol doesn't know about multipart. If we
would like to re-use the proper CoAP content-type system, it means each
possible combination of multipart that is being used or returned should get its
own unique Content-Format ID assigned. Like Panos indicated that could amount
in our case to 4 content-formats for /skg.
The use of a generic "multipart" type (62) effectively renders the CoAP
content-format system useless for use in sub-content-format selection.
If not using this content-format system - using a query parameter is a fully
CoAP compliant next-best way to handle this situation while still using the
generic multipart type 62. The basic CoAP rules are thus still fulfilled, i.e.
the resource offers type 62 and it returns type 62 always, while the query
parameter merely influences the processing of POST on this resource as is quite
common in HTTP/CoAP operations. For example in HTTP I could POST some data to a
resource that creates different HTML layouts that can be selected by a query
parameter:
POST /genReport?layout=nice1
{ data }
It still returns one and the same content type (HTML) although the contents may
be totally different, depending on the 'layout' parameter. Same reasoning goes
for our multipart content-format. In CoAP semantics, the inner types of the
multipart are in no way bound to the requested Content-Format and may be
arbitrarily changed depending on query parameters.
But I agree this can be taken to CoRE in context of the draft-multipart-ct
discussion; see what people think about this issue.
Esko
-----Original Message-----
From: Michael Richardson <m...@sandelman.ca>
Sent: Thursday, February 14, 2019 15:38
To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>
Cc: Klaus Hartke <har...@projectcool.de>; Esko Dijk
<esko.d...@iotconsultancy.nl>; ace@ietf.org
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
Panos Kampanakis (pkampana) <pkamp...@cisco.com> wrote:
> Hmm, that is a fair point. I don't think it is warranted to register
> four more content formats for all possible format combinations in the
> multipart response.
> It looks to me that your proposal of using Uri-Query in the request in
> order for the client to define the supported formats of the requested
> resource/response is a good one.
It seems a totally adhoc way that totally subverts the content-type system.
It really seems like we need to take this to CORE.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
