Subject: [core] I-D Action: draft-ietf-core-observe-11.txt

From: [email-masked]
Date: Tue, 15 Oct 2013 02:54:10 -0700

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)       : Klaus Hartke
	Filename        : draft-ietf-core-observe-11.txt
	Pages           : 31
	Date            : 2013-10-15

Abstract:
   CoAP is a RESTful application protocol for constrained nodes and
   networks.  The state of a resource on a CoAP server can change over
   time.  This document specifies a simple protocol extension for CoAP
   that enables CoAP clients to "observe" resources, i.e., to retrieve
   a representation of a resource and keep this representation updated
   by the server over a period of time.  The protocol follows a best-
   effort approach for sending new representations to clients and
   provides eventual consistency between the state observed by each
   client and the actual resource state at the server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-observe

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-observe-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 15 Oct 2013 12:56:12 +0300

draft-ietf-core-observe-11 is the latest in a long series of updates
that resulted from the numerous comments on both
draft-ietf-core-observe and draft-ietf-core-coap from the first WGLC.

I'm glad to report that this revision now has all remaining issues
resolved. (There is, of course, always room for improvement.) It can
be found at:

Diff from -10:

Best regards,
Klaus

On 15 October 2013 12:54,  <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "weigengyu" <[email-masked]>
Date: Mon, 21 Oct 2013 22:25:17 +0800

Hi， Klaus，

I have question about "1.2 protocol overview"

" A client remains on the list of observers as long as the server can
  determine the client's continued interest in the resource.  The
  interest is determined from the client's acknowledgement of
  notifications sent in confirmable CoAP messages by the server: If the
  client actively rejects a notification or if the transmission of a
  notification times out after several transmission attempts, then the
  client is assumed to be no longer interested and it is removed from
  the list of observers."

After the client sent a request to the server,
the server will determine the interest of the client from each 
acknowledgement of notification.

Is it possible or rational that the client explicitly tells the server about 
times or duration for the server to send notifications.
Such information should include in the request message.

Regards,

Gengyu

-----原始邮件----- 
From: Klaus Hartke
Sent: Tuesday, October 15, 2013 5:56 PM
To: [email-masked] WG
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt

Diff from -10:

Best regards,
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Oct 2013 16:30:07 +0200

On Oct 21, 2013, at 16:25, "weigengyu" <[email-masked]> wrote:

> Is it possible or rational that the client explicitly tells the server about times or duration for the server to send notifications.

I'm not Klaus, but maybe I can answer this:

We used to have a lifetime in a request for an observation relationship.

People implementing this told us they never knew what to put in there.

It turns out that it is very rare in our world to be interested in status updates for, say, 60 minutes.  Much more often, you are interested, or you aren't.
So we removed the lifetime concept.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Mon, 21 Oct 2013 23:39:27 +0800

Hi, Carster,

> We used to have a lifetime in a request for an observation relationship.

The information sent from the client is the detailed requirement by times or 
dutation.
It has no relations to the lifetime or status of client or server.

> People implementing this told us they never knew what to put in there.
Different implementations will meet different requirements.
We have experince for the healthcare implementations.
There kinds of sensors, i.e. electriccadio, blood sugar, and respirator, 
connecting to smart phone by blooth,
and then through the 3G network, data are tranmitted to a dedicated server 
in the Internet.

When people want to get the data from the server (sensor) , he should know 
that.
Such requirements are clear and mostly pre-defined.

> It turns out that it is very rare in our world to be interested in status 
> updates for, say, 60 minutes.  Much more often, you are interested, or you 
> aren't.

There are no sematics for the client to change status.
There is only one condition for the server to stop sending.  That is couter 
or timer.
In the current draft,  counter and timers are also used in the protocol for 
RETRANSMISSION or after sending notifications.

The information will change the server the same means as the protocol had.

regards,

Gengyu

From: Carsten Bormann
Sent: Monday, October 21, 2013 10:30 PM
To: weigengyu
Cc: Klaus Hartke ; [email-masked]
Subject: Re: [core] I-D Action: draft-ietf-core-observe-11.txt

On Oct 21, 2013, at 16:25, "weigengyu" <[email-masked]> wrote:

> Is it possible or rational that the client explicitly tells the server 
> about times or duration for the server to send notifications.

It turns out that it is very rare in our world to be interested in status 
updates for, say, 60 minutes.  Much more often, you are interested, or you 
aren't.
So we removed the lifetime concept.

Grüße, Carsten