Re: [core] I-D Action: draft-ietf-core-observe-09.txt

[Klaus Hartke <[e-mail]>]

> 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-09.txt
>         Pages           : 29
>         Date            : 2013-07-15
>
>
> 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-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-09


Following the discussion we had in February, the major change of this
revision is that a GET request no longer can have side-effects on
other requests, and that every GET requests adds a new entry to the
list of observers. Please take a look at the draft and let me know
what you think.

observe-09 concludes the big round of changes that started with the
WGLC for observe-05 in March, 2012, except for the following two
remaining issues:

* How can a client detect that it is no longer in the list of
observers when it has successfully registered?

* How can a client cancel an observation more eagerly than by
rejecting the next confirmable notification?

There have been a few proposals over the time that are related to
these issues. These include

- the original Lifetime Option [1],
- the Pledge Option [2][3],
- the Patience Option [4],
- the Next-Notification-At-Latest Option [5],
- the new Liveliness check with Pings [6],

and

- the Condition Option with type Cancellation [7],
- the new Cancellation Message [8].

All of them have some advantages and disadvantages, and I currently do
not favor any proposal over another. Note that not all proposals have
been updated to observe-09 yet.

We should soon find consensus on which one we want to use. I propose
we do that based on running code.

If you like a proposal (or come up another one),

1. please implement both the client-side and the server-side,
2. publish the code somewhere or send me a copy by mail,
3. post a short summary of your implementation experience to the mailing list.

It would be great to have at least some feedback before the IETF
meeting in Berlin, so we can have a good discussion at the CoRE
meeting on Monday.

I plan to bring an implementation of observe-09 to Berlin. If anyone
is interested in some informal interop testing, drop me a line.

Best regards,
Klaus


[1] http://tools.ietf.org/html/draft-ietf-core-observe-01#section-3
[2] http://tools.ietf.org/html/draft-bormann-coap-misc-25#appendix-B.4.3
[3] http://tools.ietf.org/html/draft-li-core-conditional-observe-04#section-6.2
[4] http://tools.ietf.org/html/draft-li-core-coap-patience-option-02#section-2.2.3
[5] http://tools.ietf.org/html/draft-bormann-coap-misc-25#section-2
[6] http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-2
[7] http://tools.ietf.org/html/draft-li-core-conditional-observe-04#section-6.1
[8] http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-3