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

From: Yusuke DOI <[email-masked]>
Date: Sat, 03 Aug 2013 19:40:29 +0900

Dear core folks,

Because I have had no time to explain about my proposal on CoAP, please
let me do it on the ML.

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

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.

Any comments are welcome.

-- 
// Yusuke DOI <[email-masked]>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 5 Aug 2013 17:59:57 +0300

> (previous proposal has index to specify a parameter option to [i]th

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. 

> 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: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Yusuke DOI <[email-masked]>
Date: Thu, 08 Aug 2013 17:10:23 +0900

Dear Zach,

(2013/08/05 23:59), Zach Shelby wrote:
> 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.

Thanks, I just updated it with minor fixes.

http://www.ietf.org/id/draft-doi-core-parameter-option-03.txt

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

At this time, I'm a quite newbie of NetConf and am not a right person to 
say 'what added benefit'. My guess is there are good number of users of 
NetConf and they are extending their world as others do.

Regards,