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

From: [email-masked]
Date: Mon, 14 Mar 2011 16:30:04 -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)       : K. Hartke, Z. Shelby
	Filename        : draft-ietf-core-observe-02.txt
	Pages           : 19
	Date            : 2011-03-14

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 specification provides a simple extension for CoAP that
gives clients the ability to observe such changes.

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Likepeng <[email-masked]>
Date: Fri, 18 Mar 2011 03:36:31 +0000

I think the current design is better and simpler than the life-time option. I have one issue about reordering. See also Ticket #129.

The paragraph below seems to be complex. Can we simplify this a little bit? For example, we can require in the spec like this: if the observe value in the response is near or equals to 2^16-1, the observer should send a new Get request with the Observe option, if the observer wants to continue the observation relationship. Then the server can use Observe value starting from 0 to 2^16-1 again. 

A client MAY discard a notification as outdated (not fresh) under the following condition:

(V1 - V2) % (2^16) < (2^15) and T2 < (T1 + (2^14))

where T1 is a client-local timestamp of the latest valid notification received for this resource (in seconds), T2 a client-local timestamp of the current notification, V1 the value of the Observe Option of the latest valid notification received, and V2 the value of the Observe Option of the current notification. The first condition essentially verifies that V2 > V1 holds in 16-bit sequence number arithmetic [RFC1982]. The second condition checks that the time expired between the two incoming messages is not so large that the sequence number might have wrapped around and the first check is therefore invalid (but is not needed any more, because reordering is not expected to occur on the order of 2^14 seconds). Note that the constants of 2^14 and 2^15 are non-critical, as is the even speed of the clocks involved; e.g., the second check can be implemented by marking a response as fresh on reception and downgrading all responses periodically every, say, 2^13 seconds; once it has been downgraded twice, it no longer participates in freshness checks.

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2011年3月15日 7:30
收件人: [email-masked]
抄送: [email-masked]
主题: [core] I-D Action:draft-ietf-core-observe-02.txt

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 specification provides a simple extension for CoAP that gives clients the ability to observe such changes.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 18 Mar 2011 11:44:49 +0100

> I think the current design is better and simpler than the life-time option. I have one issue about reordering. See also Ticket #129.

Yes, that paragraph is a bit complex. But it's the paragraph that is
complex, not the resulting implementation, which is trivial. I guess
the text can be rephrased a bit to sound less complex.

> For example, we can require in the spec like this: if the observe value in the response is near or equals to 2^16-1, the observer should send a new Get request with the Observe option, if the observer wants to continue the observation relationship. Then the server can use Observe value starting from 0 to 2^16-1 again.

A server can use the same single variable for all observers and
resources. So if all observers sent a GET request when the variable
reaches 2^16-1, the server would be flooded with requests. I don't
think this would be a good idea.

Klaus