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

[Sebastian Hans <[e-mail]>]

Robert Quattlebaum wrote:
> 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.
> 
I agree CREATE/DELETE makes a lot of sense also for very small devices 
that are expected to live for a long time. In the ETSI M2M group they 
discuss the management of such devices and the creation and update of 
files for network settings and other resourced on the device.

-Sebastian Hans

> 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] <xmpp:[e-mail]>
> eMail:  [e-mail] <mailto:[e-mail]>
> www:     <http://www.deepdarc.com/>http://www.deepdarc.com/
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core