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

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 28 Oct 2010 18:10:28 +0800

Hi Klaus,

I have few questions on your draft.

In section 2.2(Notification), I don't see why the remaining lifetime
value is sent in the notification messages. If the server decides to
change lifetime then such an option can be sent. Otherwsie I don't see
the need for remaining lifetime value in notify messages. Thus I don't
understand the need for a MUST in your draft for the remaining lifetime
value.

Furthermore, is the remaining lifetime value carried in the subscription
lifetime option?

Also one more question on Open issues. It is mentioned that mapping will
be highlighted as to how to map to HTTP bi-directional mechanisms
Why mapping specific to long polling, streaming and web socket being
considered.  Isn't there a case the observe mechanism interworks with
normal HTTP.
Or do you forsee, mapping to bi directional HTTP poses more problems?

What is the benefit of this mechanism (subject/observe) and what is the
use case. 
The benefit is the device need not query often. But if there is an ACK
for the notify then there wont be much savings in signaling.  The only
benefit is that the resource chnages can be observed in real time. Then
what is the use case. In which M2M application you will want this as
opposed to the client performing the query. Just a clarification.

BR,
Mohana

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Constrained RESTful Environments
Working Group of the IETF.

	Title           : Observing Resources in CoAP
	Author(s)       : K. Hartke, Z. Shelby
	Filename        : draft-ietf-core-observe-00.txt
	Pages           : 12
	Date            : 2010-10-18

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 a design for such an addition to
CoAP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-observe-00.txt

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 28 Oct 2010 18:41:03 +0200

Mohana Jeyatharan wrote:
> is the remaining lifetime value carried in the subscription
> lifetime option?

Yes.

> understand the need for a MUST in your draft for the remaining lifetime

The default value of the Subscription-Lifetime Option is 0 seconds. So
if a notification message does not contain the Subscription-Lifetime
Option, this means that the server ended the subscription and the
client needs to resubscribe if it wants to continue observing the
resource.

Also, the remaining lifetime can be used to detect if notification
messages got reordered, although this hasn't been formalized yet.

> considered.  Isn't there a case the observe mechanism interworks with

As I said elsewhere, I believe the way to map CoAP-observe to HTTP is
by defining a method to observe resources in HTTP, and then define how
to translate between the two methods.

There are lots of possibilities how to observe resources in HTTP. Long
polling, eventsource and web sockets are just what I have at the top
of my head. Wikipedia lists several approaches to push data from a web
server to a web browser [1,2]. And, of course, it's also possible to
explore approaches for scenarios that are not restricted to a web
browser talking to a web server (e.g., subscribing call-back URIs to a
resource if both parties act as an HTTP server). All these approaches
have different properties; none of it was really designed for
observing resources. So it should be evaluated which is the best fit.
It might even make sense to define more than one mapping.

Klaus

[1] http://en.wikipedia.org/wiki/Comet_(programming)
[2] http://en.wikipedia.org/wiki/Push_technology

---

From: "mohana Jeyatharan" <[email-masked]>
Date: Fri, 29 Oct 2010 15:38:59 +0800

Hi Klaus,

Thanks for your response. Please see below.

BR,
Mohana

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Klaus Hartke
> Sent: Friday, October 29, 2010 12:41 AM
> To: [email-masked]
> Subject: Re: [core] Comments on draft-ietf-core-observe-00
> 
> Mohana Jeyatharan wrote:
> > is the remaining lifetime value carried in the subscription lifetime
> > option?
> 
> Yes.
> 
> > understand the need for a MUST in your draft for the remaining
> > lifetime value.
> 
> The default value of the Subscription-Lifetime Option is 0 seconds. So if
a
> notification message does not contain the Subscription-Lifetime Option,
this
> means that the server ended the subscription and the client needs to
> resubscribe if it wants to continue observing the resource.

Ok, so since there is a default value defined and if subscription life time
option is not sent, then the 
client will interpret at the end of subsciption. Ok understood. So, in that
case the subscription lifetime option
needs to be sent, otherwise client will not process the notify messages.

> Also, the remaining lifetime can be used to detect if notification
messages
> got reordered, although this hasn't been formalized yet.

This part I am not very clear. I was thinking transaction ID can solve this
re-ordering issue.
Because in the draft every new notification is using a incremental
transaction ID.

> > Also one more question on Open issues. It is mentioned that mapping
> > will be highlighted as to how to map to HTTP bi-directional mechanisms
> As I said elsewhere, I believe the way to map CoAP-observe to HTTP is by
> defining a method to observe resources in HTTP, and then define how to
> translate between the two methods.

So are you saying a new method in CoAP has to be designed to solve this
observing HTTP resources?
Currently CoAP does not have a method for this..
Not very clear on this. 

> There are lots of possibilities how to observe resources in HTTP. Long
polling,
> eventsource and web sockets are just what I have at the top of my head.
> Wikipedia lists several approaches to push data from a web server to a web
> browser [1,2]. And, of course, it's also possible to explore approaches
for
> scenarios that are not restricted to a web browser talking to a web server
> (e.g., subscribing call-back URIs to a resource if both parties act as an
HTTP
> server). All these approaches have different properties; none of it was
really
> designed for observing resources. So it should be evaluated which is the
best
> fit.
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 10:41:30 +0300

> Because in the draft every new notification is using a incremental

You can't assume that. TIDs may very well be implemented to change randomly or decrease linearly... 

Klaus has an interesting point, although that might not be the most reliable way to do it (what if your CoAP implementation automatically updates the subscription lifetime, but some application doesn't realize it?). I usually recommend the payload data to include a sequence number or timestamp if this is important. 

Zach

-- 
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: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 10:53:06 +0300

>> It might even make sense to define more than one mapping.

I totally agree with this analysis. 

After implementing several CoAP to HTTP proxies, it has only become clearer that on the HTTP side there must be multiple ways provided to access resources. I find the built-in coap-observe extension ideal for a proxy to keep its cached CoAP representations fresh, and for this use case the URI is the best way to identify the notifications (Token requires unnecessary state). Once the resource is cached, it can be provided to HTTP clients in any number of ways, and the same resource could be made available to multiple HTTP push mechanisms simultaneously. I am not even convinced that we need to define any mappings for observe (although examples would be nice). It is enough that CoAP has mechanisms that a proxy can use to retrieve CoAP resources, and observe is a really useful one.  

Zach

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 29 Oct 2010 11:05:46 +0300

> After implementing several CoAP to HTTP proxies, it has only become clearer that on the HTTP side there must be multiple ways provided to access resources. I find the built-in coap-observe extensio…
it really depends on which HTTP bidirectional technique you are going to 
use.
For HTTP long polling I am not convinced neither there is any need to 
define mapping for observe.

However for WebSocket (HyBi wg) there is a need to specify an usage for 
CoAP as you may want use WebSocket not only to receive notification/observe
but also to send other kind of CoAP requests.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com