Subject: [core] draft-ietf-core-observe-05 - "obs"

From: Klaus Hartke <[email-masked]>
Date: Tue, 17 Apr 2012 02:14:27 +0200

In the spirit of "In protocol design, perfection has been reached not
when there is nothing left to add, but when there is nothing left to
take away" [1]:

Do we really need the "obs" link attribute?

Some thoughts:

* If a client wants to have a fresh representation of a resource over
a period of time, it can include the Observe option in its request. If
the server does not support -observe, the client can poll the resource
to achieve its goal.

* If a client for whatever reason only wants to have a fresh
representation of a resource over a period of time if the server
supports -observe, it can include Observe option in its request and
not poll if the if the server does not support -observe.

* If a client wants a single snapshot representation of a resource, it
can omit the Observe option from its request.

Under what circumstances can a client not be sure if it wants to have
a fresh representation of a resource over a period of time, so a hint
from the server is needed?

Klaus

[1] http://tools.ietf.org/html/rfc1925

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 17 Apr 2012 09:19:44 +0200

I'm waving the flag for poor 'obs' here.

It could provide a useful hint for a HTTP user agent that needs to take some decision about how to access the resource through a HTTP-CoAP proxy (e.g. use hanging GET instead of "usual" GET).

[ See section 4.3.4.1.1.1. of the HTTP-CoAP mapping I-D -- wow, six levels of indirection.  That's deep  nesting indeed :-) ]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 11:36:29 -0600

I'm weakly in favor of keeping 'obs' 

(but very supportive of the general idea of figuring out what we can get rid of - so thanks for raising this)

On Apr 17, 2012, at 1:19 AM, Thomas Fossati wrote:

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Apr 2012 17:12:17 +0200

> Do we really need the "obs" link attribute?

Today?  No.
A client can always simply send the Observe option and see what the server does.
(Well, maybe obs also is a hint what *kind* of resource this is.)

In the future, we might have a number of extensions like (or unlike) -observe that a server can offer.  I think it is generally better to clarify the presence or absence of an extension at the discovery stage than requiring all those extension options (the ones that would make sense for the client) to be sent with the request.

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 20 Apr 2012 18:38:37 +0300

Hi,

I would like to keep the 'obs' link attribute. From the experience deploying products and systems using CoAP so far, we have actually found this attribute useful. Two reasons:

1. Although in theory the protocol still works through trial and error as you describe below, it is useful for a CoAP client to plan its behavior before making a request.

2. Knowledge of the Observability of a resource is useful at the application layer, where some M2M application needs to make use of these resources. The behavior of dealing with a polling-only resource vs. an observable resource is pretty different, and an observable resource might result in a different graphical representation to the user which needs to be known already during discovery.

I like the philosophy otherwise for finding things to take away, but not this one please.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
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: Klaus Hartke <[email-masked]>
Date: Sat, 21 Apr 2012 04:52:44 +0200

Zach Shelby <[email-masked]> wrote:
> The behavior of dealing with a polling-only resource vs. an observable resource is pretty different, and an observable resource might result in a different graphical representation to the user which needs to be known already during discovery.

That's an aspect I hadn't considered so far and find very useful.

Maybe we could expand section 7 of -observe a bit to give advice in
this direction?

Klaus

---

From: Zach Shelby <[email-masked]>
Date: Sat, 21 Apr 2012 09:27:41 +0300

> Maybe we could expand section 7 of -observe a bit to give advice in

Sure. A couple sentences on where an indication of 'obs' can be useful is a good addition. 

Zach

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 30 Apr 2012 20:11:14 +0200

> 2. Knowledge of the Observability of a resource is useful at the application layer, where some M2M application needs to make use of these resources. The behavior of dealing with a polling-only reso…

So, to understand this in the greater context of web linking: if HTML
had an "obs" attribute for <img> links, then I guess

    <img src="/temperature/graph.png" obs>

would indicate that a user agent should observe the resource and
update the presentation whenever a new version is available ("data
monitoring"), while

    <img src="/temperature/graph.png">

would retain the existing semantics of retrieving the image once and
not updating the presentation until the page is reloaded ("data
retrieval").

So it seems that the "obs" attribute is orthogonal to supporting
-observe: The question is not polling vs. observing a resource, but
whether the resource is meant for data retrieval or data monitoring.
If a server indicates that a resource is meant for data monitoring but
does not implement -observe (or is temporarily not accepting -observe
requests), it still makes sense for a client to present the resource
in the "data monitoring" graphical representation and poll the
resource if necessary to achieve this goal.

Klaus