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

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Jun 2010 22:49:12 +0200

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 <[email-masked]>
> Date: June 22, 2010 22:35:27 +0200
> To: [email-masked]
> Cc: [email-masked]
> 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.
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 23 Jun 2010 18:24:11 +0300

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:

> _______________________________________________
> core mailing list
> [email-masked]
> 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: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Jun 2010 18:55:54 +0200

Zach,

that are a number of very good questions.

> - 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 im…

Right now, CoAP is silent on how much time a server has to answer a request.

Certainly, that time will never be zero.

Can we live with limiting this time to < RESPONSE_TIMEOUT hard?

If yes, everything gets simpler.
If not, there is always the alternative not to do an inversion of control; in that case, the server would reply with a "please wait and try again", maybe including a duration that gives the estimated time until an answer, and the client would simply repeat asking at its convenience.
(Of course, the server could simply remain silent, prompting retransmissions, but this means that we limit the time to RESPONSE_TIMEOUT * MAX_RETRANSMIT, assuming no errors, and we increase the likelihood of a transfer failing just because of lost packets.)

On the other hand, if we do have a "notify" style packet, there is very little stopping us from implementing an "I'll give it to you later" reply (the "ACK" packet in Figure 1 of coap-observe).  A client that doesn't want to wait can simply treat that as a failure.

As usual, we should probably err on the side of simplicity, but only after having discussed whether we are hitting Einstein's "but no simpler".

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 24 Jun 2010 10:46:24 +0200

Possible solution: CoAP server, if the final response will be
available after RESPONSE_TIMEOUT, must send a response with code 100
Continue (HTTP).

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1

However in this discussion application level and transport level
issues are handled at the same time... Is it convenient?

Angelo

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 24 Jun 2010 19:52:56 +0200

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

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 b…

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 min…

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…

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

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Fri, 25 Jun 2010 10:23:01 -0400

>> 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.
> favour of .xml in the URL.

Wouldn't relying on URI file extensions to determine format be more
complicated and potentially result in more transactions?

What I'm thinking here is that file extensions are not always as
standardized as one may hope and multiple extensions may exist for a
single format (HTML comes to mind, with .htm and .html).

Why the opposition 'Accept: style headers' (provided done in a compact
binary way)?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Jun 2010 16:58:41 +0200

> Why the opposition 'Accept: style headers' (provided done in a compact

Probably because they are ugly in the Web (too many choices for a typical UA) and we learned to hate them.

They needn't be ugly in the M2M Web.
And I'm also not a big fan of filetypes (even though they do have the advantage of bundling the representation request information in the URI, this is also a disadvantage).

I just added a proposed Accept option to my misc draft and uploaded the new version as draft-bormann-coap-misc-01, if you want to see one possible design.

Gruesse, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 25 Jun 2010 18:34:25 +0200

> single format (HTML comes to mind, with .htm and .html).

I didn't mean to attach meaning to file extensions.

If a server is able to offer a resource in multiple representation
formats, it could (for example) recognize the following URLs:

</sensor/temp>; type=application/x-temperature;
</sensor/temp.xml>; type=text/xml;
</sensor/temp.json>; type=application/json;
</sensor/temp.txt>; type=text/plain;

A client can then simply request a specific representation by choosing
the corresponding URL.

With an Accept: header, "/.well-known/resources" would probably look like this:

</sensor/temp>; type=application/x-temperature, text/xml,
application/json, text/plain;

and a client can request a specific representation by including one of
the values in the Accept option.

Klaus

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Jun 2010 22:36:05 +0300

Klaus,

A few agreements in-line.

> architecture. Whether all elements of the architecture are needed,

Good point. 

> favour of .xml in the URL.

+1

> is a requirement that should be stated somewhere.

+1

> probably not be that different from what we have in coap-00 currently.

Yep, this is what I thought. 

Zach

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Jun 2010 22:39:09 +0300

Hi Robby,

> Why the opposition 'Accept: style headers' (provided done in a compact

This could be a backup. But we might not need that, as the resource discovery includes a description of the content-type for a resource. Using that you know what representation will be returned a priori. I don't expect that constrained resources will be offered in many formats at the same time though? What do you think?

Zach

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Mon, 28 Jun 2010 15:49:23 -0400

I think depending on resource discovery to give content-type could prove
problematic.

First, this introduces tighter coupling between resource discovery and
application transport.  Now devices must maintain more state between the
two -- in other words, a device must remember the resources that are
exposed in the appropriate format, though this could allow a device to
only remember resources which in formats it prefers.

Second, this requires that resource discovery be granular all the way to
each addressable resource.  For example, I could envision resource
discovery that only points a device in the direction of a set or
hierarchy of resources.  However, if content-type is (only) clearly
specified during resource discovery, then a device would need to learn
of each resource via resource discovery.

I agree that constrained devices may not offer many formats
simultaneously, though I hate to make the assumption.

- Robby

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Monday, June 28, 2010 3:39 PM
To: Simpson, Robby (GE Energy Services)
Cc: core
Subject: Re: [core] Fwd: New Version Notification
fordraft-hartke-coap-observe-00

Hi Robby,

> Why the opposition 'Accept: style headers' (provided done in a compact

This could be a backup. But we might not need that, as the resource
discovery includes a description of the content-type for a resource.
Using that you know what representation will be returned a priori. I
don't expect that constrained resources will be offered in many formats
at the same time though? What do you think?

Zach

---

From: Zach Shelby <[email-masked]>
Date: Tue, 29 Jun 2010 00:06:03 +0300

Bingo, I have been thinking about this more and to me it seems like dealing with asynchronous responses to delayed normal requests (not subscriptions) is actually the key piece we have been missing. We need this kind of asynchronous response (notification) for this purpose. So what if we build this observation thing like:

1. Integrate this asynchronous response message into the core protocol for the purpose of normal requests. This might be similar to the current notify message, or a different kind of response. I think this is what Robert Cragie was getting to before, asynchronous interactions are key here.

2. We consider the observation feature as just another way to invoke asynchronous responses. If we consider that GET can be answered later asynchronously. Then adding a subscription is simply a GET with some more specific meta-data (subscription/observation option). That also makes the HTTP mapping more like what some were hoping for?

Both 1 and 2 are part of the transfer protocol interaction model, and can be done transparently to the REST methods. I start to see a way we could achieve both the observation and notification without requiring new methods and making it possible for a more "transparent" HTTP mapping even for observation.

> Can we live with limiting this time to < RESPONSE_TIMEOUT hard?

Nope, I think you are right that we need asynchronous responses.  

Zach