Re: [core] Comments on draft-shelby-core-coap-00 and draft-shelby-core-coap-req-00

[Zach Shelby <[e-mail]>]

Hi Robert,

Thanks for the comments. 

On Apr 20, 2010, at 2:32 , Robert Quattlebaum wrote:

> Hello!
> 
> Here are my comments on draft-shelby-core-coap-00: (Separated by '-----')
> 
> What is the use case for the CREATE and DELETE methods? Wouldn't the resources exposed by a device be somewhat static? What sorts of resources would I be creating or deleting on a temperature sensor, a power meter, or an appliance module?

I am actually updating these methods to be called GET, PUT, POST, DELETE as the semantics are very similar. One example of creating/deleting a resource on a sensor node would be on some configuration parameter which needs a list of things. RESTful interfaces actually make pretty heavy use of all 4 methods. 

> 
> -----
> 
> I think that the UPDATE method and the NOTIFY method could be combined into one method. I believe that it would be relatively easy to design the protocol in such a way as to make this distinction unnecessary. (Elaborated on in my comments on draft-shelby-core-coap-req-00, below)

Yep. Currently I am working on removing the NOTIFY method and instead am defining a proper notification message type as suggested by Robert Cragie. 

> 
> -----
> 
> I am assuming that, since URLs are being used, a physical device contains a hierarchy of nodes (Resources?) which can be read, updated, etc. If so, a explicit way to walk thru the hierarchy would be needed. I would recommend a walk-type mechanism (requiring multiple queries) as opposed to 'READ' returning all of the subnodes/resources---because the list of subnodes/resources may not fit into a single packet. It would also likely be easier to implement a walking system on highly constrained devices.

RESTful URls work in a walk thru way. That is, if you GET /sensors that will probably only return the links to sensors whereas if you GET /sensors/temp that will likely return the representation of temperature. Note that I say probably/likely as it is totally up to the server what is returned. This works in the same way as HTTP.

> 
> -----
> 
> Additional error codes worth considering:
> 
> 	• 401 Unauthorized
> 	• 403 Forbidden
> 	• 405 Method Not Allowed
> 	• 409 Conflict
> 	• 500 Internal Server Error
> 	• 503 Service Unavailable
> 	• 504 Gateway Timeout

What would 409 be used for? The others I can understand. Am planning a section to list all the codes supported. 

> 
> -----
> 
> For the URI codes: 256 values may not be enough. Perhaps an adaptive encoding allowing for larger indices is warranted. A possible encoding scheme would be similar to the EXI Unsigned Integer encoding: <http://www.w3.org/TR/exi/#encodingUnsignedInteger>. This integer encoding could also be used for the content-type encoding---which would reduce the size of that option by a byte for the 128 most common content types.

Sure, that scheme would work nicely. Will consider it. Although you don't need to assign a code to every URL, only to the most commonly used ones if you want to save overhead. Thus you will rarely run out of those 256 codes. 

> 
> -----
> 
> I am unconvinced of the utility or practicality of a TCP interface for this protocol. In any case where TCP would be considered, I think a protocol such as HTTP would likely be better suited. My thinking is that any device powerful enough to do proper TCP would surely be powerful enough to do simple HTTP.

You know, I totally agree with that approach. The recent conversations around SCTP and UDP/TCP negotiation have made me even more unsure if we need to define a TCP binding at all. Maybe we end up just saying that if you want to use TCP, then go ahead and use HTTP (okay, shoot me) ;-)

> 
> -----
> 
> Here are my comments on draft-shelby-core-coap-req-00:
> 
> Having a push model be a requirement is a good thing, but I do not think that a subscribe/notify mechanism is the ideal way to go. I think a more flexible approach is one where each device exposes "events" (resources which push) to "actions" (resources which do something when they receive a push). Events are then "paired" to actions, using some sort of administrative interface. This gives you a huge amount of flexibility.

Right, you can do this with CoAP notification. The subscription will be just *one* way of setting up notifications. CoAP is just a transfer protocol (like HTTP) whereas you need to develop your own protocol logic. That logic may very well set up such event pairing and make use of the notification feature of CoAP. I also find unsolicited (pre-configured) notifications to be useful in many cases.

Cheers,
Zach

> 
> This was the model I was using for "SCMP", which I document in considerably more detail here: <http://www.ietf.org/mail-archive/web/core/current/msg00119.html>
> 
> For example, lets say that you have a light switch module and an appliance module. The module has a 'state' variable, that is either 'on' or 'off'. The state variable would have three events associated with it: 'changed', 'turned-on', and 'turned-off'. The payload is the same for each event, but 'turned-on' only fires when the switch is turned on, and 'turned-off' only fires when the switch is turned off. The appliance module has a 'state' variable as well, and it has the following actions: 'set', 'turn-on', and 'turn-off'. The 'set' action would update the 'state' variable to match the payload of the event, assuming the content-type of the event matches the type of the 'state' variable. The 'turn-on' and 'turn-off' events would change the state variable to 'on' or 'off' respectively, ignoring the payload of the event. In general events and actions don't have to be associated with variables, but I'm doing so here for the sake of clarity.
> 
> You can pair the 'changed' event to the 'set' action, and then the light switch would control the appliance module. In this case, the 'set' action is getting the value to set from the payload of the 'changed' event. (This is why I suggest that the 'UPDATE' and 'NOTIFY' methods could perhaps be merged into a single method)
> 
> Alternatively, you could have an inverse relationship: You could pair the 'turned-off' event to the 'turn-on' action, and pair the 'turned-on' event to the 'turn-off' action. Now whenever the light switch is 'on', the appliance module is 'off', and vise-versa. This works because the 'turn-on' and 'turn-off' actions don't care what the payload of the event they are receiving is---they perform a specific action whenever they are triggered. 
> 
> I think this mechanism is superior to the subscribe/notify mechanism for the following reasons:
> 
> 	• Additional metadata or actions can be associated with a pairing (such as reliability requirements).
> 	• Security credentials can be created per-pairing. This way, if a device is completely compromised the only actions an attacker can take are the ones already paired. 
> 	• One-to-many pairings could be created that would use IPv6 multicasting for more efficient network utilization, while still maintaining the security credentials described above. 
> 	• All pairings happen at setup, so if any resource constraints are exceeded (i.e. too many pairings) it is known at configuration time. If subscriptions happen at run-time, then device resources could be exhausted under certain circumstances causing some subscriptions to fail.
> 
> Pairings could be made in one of two ways:
> 
> 	• Using a user interface on a computer.
> 	• Using a simple push-button pairing for simple, pre-defined device relationships. (e.g. light switch to lamp, volume knob to a stereo, temperature control panel to an HVAC system, etc.)
> 
> There are a lot of implementation details I'm skipping over for the sake of clarity. Please don't hesitate to ask if you want me to clarify or elaborate on any of the point I have made.
> 
> Thoughts?
> 
> __________________
> Robert Quattlebaum
> Jabber: [e-mail]
> eMail:  [e-mail]
> www:    http://www.deepdarc.com/
> 
> 
> 

-- 
Zach Shelby, Head of Research, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]