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

[Klaus Hartke <[e-mail]>]

On 23 June 2010 17:24, Zach Shelby <[e-mail]> wrote:
> - 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.

Of course. If SUBSCRIBE has no meaning for a resource, it's not
required to offer that method ("405 Method Not Allowed"). If you
restrict a server to have no resources that allow SUBSCRIBE, such code
minimization is possible.

> - Are we sure we need all the requirements here, or are some nice-to-have?

I believe that all requirements are needed to implement the
architecture. Whether all elements of the architecture are needed,
should be discussed.

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

I think both options (/sensors/temperature.xml or Accept:
application/xml) are valid ways to satisfy this requirement. If we go
with the Accept header, we need to add a new option to CoAP. I'm in
favour of .xml in the URL.

There is another requirement related to the representation format,
which is probably more important: "The representation format used
during the lifetime of a subscription must not change." I think this
is a requirement that should be stated somewhere.

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

The list of requirements aims to be exhaustive, but many requirements
can be satisfied by introducing very simple protocol elements (such as
confirmable requests). I think the message exchanges in
coap-observe-00 (section 4) are already quite pleasing to the eye.

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

Carsten and I are working on concrete message types. The result will
probably not be that different from what we have in coap-00 currently.

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

Yes. YIELD mainly carries a representation, but it may also just
indicate that the resource changed to one of the states cached by the
client ("304 Not Modified"). THROW mainly carries an error code (e.g.,
404, 401 or 500), but I think it might also be useful to be able to
include diagnostic information in the payload for debugging purposes.

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

I'm currently experimenting with an implementation that does way 2.
The implementation so far is very elegant and clean, requires less
state, and uses smaller messages. But I haven't made up my mind yet.

Klaus