Re: [core] About draft-doi-core-parameter-option

[Zach Shelby <[e-mail]>]

On Aug 3, 2013, at 1:40 PM, Yusuke DOI <[e-mail]> wrote:

> CoAP uses (discrete) content-format to describe combination of
> content-type and media type parameters. Content-Format is also used by
> Accept option and I suppose more than 99% of expected communications in
> CoAP is okay. However, some communications that requires free-format
> parameter on media types (including EXI schema nego that is used in
> ZigBee SEP2.0) is not possible in CoAP. Of course, there is a workaround
> to define 'per-resource' parameter and put it on URI path. However, this
> hinders (for example) use of CoAP-HTTP GW without per-resource knowledge
> on media type parameter and resource parameter mapping.
> 
> My proposal update is now focused on server side content negotiation and
> thus it only defines parameter options for the Accept option. Because
> CoAP now has only one Accept option, the format is also simplified
> (previous proposal has index to specify a parameter option to [i]th
> Accept option).

Did you submit a new version of the draft updated with this? I guess you are asking for reviews and comments, just making sure what version to look at. 

> FYI: There is a proposal on NetConf to use EXI. Currently, there is no
> adpotion of CoAP on NetConf (there is another proposal on RESTful API of
> NetConf). But I think this could be an interesting combination: NetConf
> RESTful API transported over CoAP.

In the COMAN discussion group we have been coming to the conclusion that a RESTful representation of MiBs would be very useful. I am not sure what added benefit a RESTful representation of NetConf would necessarily serve? I would think that would be more useful for proxying NetConf to HTTP. 

Thanks,
Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net