Subject: [core] Comments on draft-ietf-core-observe-00

From: Vipul Gupta <[email-masked]>
Date: Tue, 26 Oct 2010 15:58:47 -0700

The draft describes a mechanism for CoAP clients to observe changes 
to a resource. In my experience (primarily with Sensor.Network [1]),
it is more useful to be able to subscribe to specific changes to a 
resource, e.g. when the soil moisture falls below a certain threshold 
or an object being tracked enters a given geographical area (geo-
fencing). If the client were to be notified upon every change to 
the resource (moisture or location) in these situations, it would 
be quickly overwhelmed. While the current draft offers an improvement 
over periodic polling of the resource by a client, I feel it doesn't 
go far enough to be really useful.

I also find the use of GETs to create a subscription unweildy. A 
POST to a subscription URL for a resource seems to fit the REST model 
much better. Webhooks (see http://wiki.webhooks.org/RESTful-WebHooks) 
is emerging as a popular way to do notifications with HTTP. Resources 
that allow subscriptions include their subscription URL as part of the
HTTP link header and subsriptions are created via a POST to the subscription 
URL. Notifications take the form of HTTP POSTs to a URL (the 
notification end-point). The POST body in the subscription request can 
be used to specify not only the notification end-point but also the 
specific changes the client is interested in. 

We will need to nail down some additional details but adopting 
something based on Webhooks here would address limitations of the 
current draft (e.g. in applications like geo-fencing, multiple 
clients need to create subscriptions with different criteria on 
the same resource). In addition, it will make HTTP mapping much 
easier. For example, it isn't clear from the draft how multiple 
responses to the GET are mapped to HTTP at an HTTP<->CoAP gateway.

vipul

--
[1] For more info, see http://sensor.network.com/ or
    the presentation/paper on Sensor.Network at 
    http://www.webofthings.com/wot/2010/program.php

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 27 Oct 2010 02:52:28 +0200

It sounds like you actually want to observe a resource
coap://server/tracked-object/is-in-area-51 and not
coap://server/tracked-object/current-position.

When you expose your sensors over CoAP, you need to model the sensors
as RESTful resources. The most basic way to do this, is to expose the
state of the subject itself, e.g., the current temperature in some
room. But that's not the only way, there are other ways to expose the
state as well. You can create a resource whose state indicates whether
the temperature is currently above 40*C or not. You can create a
resource whose state is the average of the temperature in the last 30
minutes. You can create a resource whose state indicates whether the
temperature was above 40*C in the last 30 minutes. The possibilities
are endless. It depends on what clients are really interested in.

And remember that resources can be paramterized. You don't need to
create a resource for each possible threshold. You can create a
resource coap://server/soil-moisture?is-below-threshold=X which can be
observed and which indicates if the soil moisture is below threshold
X, rather than returning the soil moisture. Different clients can
observe the same resource with different parameters, and be notified
depending on what they're individually interested in.

So the current observation mechanism is already quite powerful, and in
my opinion it fits very well into a RESTful architecture as is. Like
the block/slice draft extends a GET request in the space dimension,
the observe draft extends a GET request in the time dimension. We use
GET, because that's what GET does - retrieve a representation of the
state of a resource: with block/slice at different locations, with
observe at different points of time.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 27 Oct 2010 03:56:30 +0200

The difference between CoAP and HTTP is that HTTP doesn't have a
built-in way to observe the changes to the state of a resource. That
makes the HTTP/CoAP mapping slightly more difficult than just
translating messages between CoAP and HTTP syntax, but doesn't mean we
shouldn't have observations in CoAP.

The way to map CoAP-observe to HTTP is to implement the same design
pattern in HTTP and then map between the two incarnations.

There are many ways to implement the subject/observer design pattern
in HTTP. Possible options include long-polling, WebSockets, or
Server-Sent Events (eventsource).

If an HTTP client wants to observe a CoAP resource, it uses the HTTP
observation mechanism to talk to the HTTP/CoAP gateway, and the
HTTP/CoAP gateway uses CoAP-observe to observe the desired resource on
behalf of the the HTTP client.

So, for example, in the case of Server-Sent Events, the gateway will
need to transform the multiple responses to the CoAP GET request to
multiple event stream events.

We don't need to make observing the state of resources complex just to
make the mapping to HTTP simple.

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Tue, 26 Oct 2010 21:11:26 -0500

The Webhooks approach is interesting, though the requirement that the
resource owner notify by posting through a second party may be too
inefficient in a constrained environment (it does nicely decouple the
notification from the decision of whether to use sequential unicast or
multicast).  This solution seems almost in line with my suggestion that
observation be simply a way of applying CoAP: if you have different needs
you can do it a different way.

I think the implementation of the webhooks approach in CoAP might benefit
from adding a Notification-Type header, though this could also go in the
body along with the multiple link descriptions used in some situations.  If
we had provision for user-defined options, it would be easy for people to do
this and other observe variants (excluding those that affect the transaction
state machine) without creating any more interoperability problems than
private IP-based services supported in the dynamic port range.  Any such
solution that got significant market share could easily be made standard
with controlled option values.

Peter

On Tue, Oct 26, 2010 at 5:58 PM, Vipul Gupta <[email-masked]>wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Peter Bigot <[email-masked]>
Date: Tue, 26 Oct 2010 21:11:29 -0500

The selection of how to model the resources (event or state) is clearly an
application choice; similarly the application would necessarily be involved
in any decision regarding filtering based on values.  With that much
application involvement anyway, I'm really not seeing a compelling need to
also involve the protocol.

The proposed coap-observe solution is indeed powerful.  I don't see it as
necessary.  Every use case I've encountered can be solved with base coap.
Nor do I see it as RESTful.  Resources are already a temporal map (Fielding
# 5.2.1.1) ; GET is expected to produce a representation of the resource at
the current time (unless the definition of the resource includes a
historical aspect, in which case it's still the value of that historical
content as known at the current time).  Extending a single get request
across time (or perhaps it's across an axis representing state change
events) doesn't make sense to me within a REST model.  Acknowledging that
CoAP need not be REST, I am still concerned with how this approach
complicates the basic transaction state machine by allowing multiple
responses to a single request.

coap-block, in turn, does solve a problem that exists in base coap (transfer
of large representations), though I think the newer concepts also take it
away from being RESTful (by introducing internal structure that is not
reflected in the resource URI).  Again, irrelevant to whatever degree you're
uninterested in requiring CoAP to be REST-compatible all the way down.
Nontheless, having re-read the TFTP spec (RFC1350), my preference is still
to redirect large transfers to that protocol.  Extremely simple, designed
specifically for constrained environments, and over eighteen years in the
field proves it works.  Only thing required in some cases is to implement
RFC2348 to get the packet size down to where it'll work in a constrained
network.

Peter