Re: [core] Fwd: New Version Notification for draft-hartke-coap-observe-00

[Zach Shelby <[e-mail]>]

Klaus, Carsten,

Wow guys, you really put a huge amount of work into analyzing this. Thanks! 

At the abstract level, I think you have captured the requirements and general concept of what we want to achieve very well. I think it is an important point in your draft that CoAP is a RESTful transfer protocol, not an application protocol. Therefore, support of resource observation is at the transfer protocol level, and is transparent to the application. 

Here are some initial comments:

- The requirements are good, however we should not require an end-point to support observation for its resources. It is up to the server if a resources is "observable" or not, and thus very simple end-points may leave that feature out to minimize code size.

- Are we sure we need all the requirements here, or are some nice-to-have? For example: "A subscribing client must be able to influence the representation format in which the server supplies the resource state" I would hope this doesn't end up resulting in a bunch of Accept: style headers? Couldn't that be left to the application to offer URLs with different representation formats? I am not convinced this should be a transfer protocol requirement for CoAP.

- At first glance this looks overly complicated, but I think it is because you are modeling this as a format design pattern and are exploring this is detail. I am hoping that realizing this would be a whole lot simpler? 

- SUBSCRIBE, UNSUBSCRIBE, YIELD, BREAK, THROW are abstract concepts at this point, I would think these could be combined quite a bit in realization? What kind of realization do you guys have in mind (just for a sneak preview to see if this is nuts or not).

- The notification messages seem to be sometimes representations and sometimes error codes. Is this suggesting that an (abstract) notification message would need to carry both a representation and a CoAP code. BREAK and THROW are also shows as being piggybacked on replies, so they basically are CoAP codes. So YEILD = representation, and BREAK+THROW = CoAP codes?

- I am not sure about the implications of allowing a delayed GET and PUT response on implementations. Currently in coap-00 if an end-point doesn't make use of subscribe/notify it doesn't have to implement code to wait for asynchronous notifications. For example it might simply make a request, open a temporary UDP socket waiting for the response, and then close that and go to sleep. Well, I guess if it gets an intermediate response code it would know to stay awake waiting for the response. Is this an efficient way of using energy in a constrained network though? What if a client doesn't want a delayed response?

- Regarding Section 6, I prefer "way 1", seems much cleaner to me, has less state and is useful in a proxy.   

Zach

On Jun 22, 2010, at 11:49 PM, Carsten Bormann wrote:

> Klaus Hartke and I have just submitted a draft on issue #1/#2.
> 
> http://datatracker.ietf.org/doc/draft-hartke-coap-observe/
> 
> We believe it is not meaningful to discuss requirements without an
> idea to what kind of design they might lead, so we provided a design
> as well.  In effect, we tried to liberate ourselves from the
> publish/subscribe/notify terminology and went back to the actual base
> requirement behind charter objective 2: being able to observe a resource.
> 
> We tried to stick to the REST model as much as possible, but we extend
> the existing HTTP methods by a method for explicitly *observing* a
> resource.  This does not necessarily require the resource to implement
> new methods, only the server offering its representations has to.
> There is some new state, but it is not much different from the
> conversation state that we already have in HTTP.
> 
> Enjoy!
> 
> Gruesse, Klaus and Carsten
> 
> 
> Begin forwarded message:
> 
>> From: IETF I-D Submission Tool <[e-mail]>
>> Date: June 22, 2010 22:35:27 +0200
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: New Version Notification for draft-hartke-coap-observe-00 
>> 
>> 
>> A new version of I-D, draft-hartke-coap-observe-00.txt has been successfully submitted by Carsten Bormann and posted to the IETF repository.
>> 
>> Filename:	 draft-hartke-coap-observe
>> Revision:	 00
>> Title:		 Observing Resources in CoAP
>> Creation_date:	 2010-06-21
>> WG ID:		 Independent Submission
>> Number_of_pages: 23
>> 
>> Abstract:
>> The state of a resource can change over time.  We want to give
>> clients of the CoRE WG CoAP protocol the ability to observe this
>> change.  This short I-D provides an example design for such an
>> addition to CoAP, in order to be able to discuss the design
>> alternatives in specific terms.
>> 
>> 
>> 
>> The IETF Secretariat.
>> 
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

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