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

[Robert Quattlebaum <[e-mail]>]

Hello Zach!

On Apr 20, 2010, at 5:46 AM, Zach Shelby wrote:

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

This makes sense. These were exactly the same method names I was using  
for SCMP, using POST for notifications.

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

Well, yes, I guess it is, but if you can't fit the list of all of the  
children of /sensors into one packet then you are in trouble. What I'm  
suggesting is providing a way to walk thru the items in a level of the  
hierarchy. For example, lets say there are 1000 sensors, but only 10  
can fit in a packet. First you would request the listing and it would  
return the first 10 and then indicate that there are additional nodes.  
You would then submit another query which includes the last item from  
the previously returned list as the 'starting point'. You would then  
continue this until you retrieved the names of all the sensors or you  
exceeded some sort of hard limit on the number of returned items.

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

409 would be used whenever there is some sort of conflict that would  
prevent the given request from being processed. For example, some  
application protocols may want their requests to represent  
transactions. If one device sends a request to another device and it  
then receives a request from the same device before receiving a  
response, it may return 409 to indicate that it can't process the  
request until the pending transaction is complete. (If both sides  
return 409 then that's no good either, so some sort of stateless tie- 
break would be needed in this case, but you get the idea)

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

I mentioned this, but later I was thinking about the possibility of  
using this protocol over RS-232 serial line... It might be useful to  
define how the protocol could be used in this way, but to recommend  
against using it over TCP. *shrugs*

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

Is that to say that the subscription/pairing mechanism would be  
defined in another draft-standard? Has there been any work on that  
yet, or should I write up some proposals and run them by you?

By the way... In the SCMP idea I was working on, devices could send  
events to other devices, and those devices may send other events when  
they receive events(Timers, room-controllers, etc). This presents the  
possibility of having event-action loop that would flood the network  
with events. I recommend adding another header, perhaps named "Cascade- 
Hop-Count" or something. For every event which is triggered by another  
event, the cascade-hop-count of the triggering event would first be  
checked to make sure it is non-zero. If it is zero, the new event  
isn't sent. If it is non-zero, it would be decremented and copied to  
the new event. This way event loops eventually die and don't take down  
the whole network.

__________________
Robert Quattlebaum
Jabber: [e-mail]
eMail:  [e-mail]
www:    http://www.deepdarc.com/