Subject: [core] Observe Cancellation: The outcome

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Mar 2014 17:08:30 +0000

After extensive discussion both in person at IETF89 and on the mailing list the CoRE WG today met to close the issue.
Two solutions emerged as the winners in their respective class:
1) a GET that looks like an Observation renewal (i.e., carries the options and the token of the ongoing request), but has a (TBD) value of the Observe option ≠ 0, cancels the Observation relationship instead.
2) a new code (0.31 possibly was the most favored one) indicates a cancel message; the ongoing request identified by the token in the cancel message is canceled.

After some more discussion, we first checked whether there was anyone that couldn’t live with one of the solutions.
Nobody showed their hands for either solution.
(Thomas indicated that he was unhappy with both, but that wouldn’t have helped with deciding.)

So we went to a hum.  There was a strong, but not unanimous consensus for solution 1.

With respect to the value of TBD, the most basic value that is different from 0 (the vale of an empty Observe option, which we use for setting up and renewing Observation relationships) is 1.
Actually, any bits beyond the low order bit of the uint in the option should be ignored just in case we want to extend the (elective) request option later.

The successful cancellation is indicated by a GET response without an Observe option.
Any need to suppress the normal response of the GET will need to be handled by additional mechanisms such as the No-response Option.

As usual, we have to validate this result on the mailing list.  Please indicate on the mailing list any serious problems you see with this result until

	2014-03-14, 24:00 UTC

We will ship -observe-13 to the IESG on that date unless there is a major issue; that will be submitted in the next couple of days.

Grüße, Carsten

---

From: Olaf Bergmann <[email-masked]>
Date: Sat, 08 Mar 2014 08:25:58 +0000

Carsten Bormann <[email-masked]> writes:

> indicate on the mailing list any serious problems you see with this
> result

FWIW, I still hold up my concerns that I have expressed earlier[0].

  [0] http://www.ietf.org/mail-archive/web/core/current/msg05323.html

Gruesse
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Mar 2014 11:32:04 +0000

>  [0] http://www.ietf.org/mail-archive/web/core/current/msg05323.html

Noted.  To move the current design into that direction, we would need to find a better way to to an observe-renew as well.
The current approach to observe-renew is near optimal in that it is single-exchange idempotent (i.e. it does not matter whether it is actually renewing an existing observation relationship or setting up an observation relationship that the server forgot about).
Apart from the fact that it interoperates well, this makes it unlikely that we want to change it at this point.
Modelling the observation cancellation in the same way means that at least you don’t have to put in another code path (i.e., you can handle observe-cancel parallel to the observe-renew logic).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Mar 2014 14:05:15 +0000

On 07 Mar 2014, at 17:08, Carsten Bormann <[email-masked]> wrote:

> There was a strong, but not unanimous consensus for solution 1.

… and I can report that we are already happily interop-testing that outcome at CoAP#4 (TD_COAP_OBS_12 for those who follow this).

You can find the new test available on the test client at http://coap.me as well (through "ETSI CoAP#4 test client”), a compatible server is up e.g. at coap://vs0.inf.ethz.ch (so the abbreviated entry point into the tests for this test pairing is at: http://coap.me/test/coap://vs0.inf.ethz.ch).  Enjoy.

Grüße, Carsten

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Sat, 8 Mar 2014 16:10:58 +0000

>(Thomas indicated that he was unhappy with both, but that wouldn’t have

Since it’s not in the meeting minutes, and for the benefit of future
generations of CoAP implementers :-) I’ll restate the concerns I’ve
expressed at the mike on Friday for the two proposed alternatives.

The main issue with cancellation is that it can’t be treated as a request
because it simply doesn't target a resource: it targets the relationship
between the resource, the observing client, and the server.  So, it's a
fairly different beast.

Strictly speaking, the text we have in section 5.1 of our soon-to-be-RFC
would theoretically rule out two things:
a) using a new request code (5-31);
b) reusing an existing request code as GET (or any other already allocated
   method).

Besides, to reinforce point b), I'd really like we do not (further)
override the semantics of a simple and well understood method as GET,
where we should be ultra careful with preserving the safe/idempotent
properties.  (Though one may argue that GET+observe already challenges the
safe-ness of GET, I’d really prefer we do not repeat the same error twice
just for the sake of “consistency".)

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Mar 2014 17:15:30 +0000

> b) reusing an existing request code as GET (or any other already allocated

(Personal view follows, no hat:)

There is no “reuse”.

This is still a GET: A client is obtaining a representation of the resource.
At the level of the REST model, there is no change: These representations are cacheable, they can be operated on by chains of proxies (“layered system”) only some of which make use of Observe, maintaining a uniform interface, and so on.

The details of how the GET request is operated are in the Observe request option (absent, =0, =1).
Setting up an Observation relationship asks for future representations as well; renewing checks and possible re-establishes it, canceling ends the indication of interest.
But this is not application state: This is entirely an optimization that saves polling (or, long-polling, which goes much further in the way of bending the REST principles).
Saying this is “not RESTful” is tantamount to claiming HTTP is not RESTful because it involves setting up TCP state.

The Observation relationship state is not modeled as a resource, because it really isn’t one.
Passing this information along with a normal GET request leads to some unneeded semantics (e.g., many use cases of a cancel do not need a final representation).  That causes tremendous cognitive dissonance in a design that is otherwise as clean as that of CoAP, but is not really a big problem in practice.

A more general comment (not directed to Thomas): I would prefer it if people actually applied the principles laid out in section 5 of [REST] before calling something more or less “RESTful”.  E.g., textual representation of protocol elements is completely irrelevant to REST (and CoAP does away with ease with this principle, which is indeed very useful in more powerful systems).  

Exercise for the reader: Find the places in [REST] where the author criticizes HTTP for getting something wrong that we did get right in CoAP.

Grüße, Carsten

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", Ph.D. Dissertation,
              University of California, Irvine, 2000, <http://
              www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.

---

From: "Peter A. Bigot" <[email-masked]>
Date: Sat, 08 Mar 2014 18:19:42 -0600

> Saying this is “not RESTful” is tantamount to claiming HTTP is not RESTful because it involves setting up TCP state.

Agreed: There is no state at the HTTP (request/response transaction) 
layer; it's present at the TCP (data transport) layer, which is 
conceptually decoupled from HTTP in a RESTful system (e.g., HTTP/SMTP).

In CoAP, the state that's being created for -observe is being created 
and destroyed as a side-effect of a GET request (transaction), and is 
identified through a transaction-layer concept (Token).  So we can say 
there's no inter-transaction state preserved in an -observe operation 
because the transaction simply hasn't completed until something causes 
it to stop; all those requests/responses over long periods are the moral 
equivalent of IP packets, and the state required to support them the 
moral equivalent of TCP state.

This is an interesting perspective, and I see the argument.

> The Observation relationship state is not modeled as a resource, because it really isn’t one.

It's not a resource only because it was decided that it shouldn't be.  
It'd be a resource if you think of handling observation this way:

1) Create a resource representing a subscription from a client to a 
server, containing the URI of the resource to be observed and a URI to 
which changes to the observed resource should be sent.  (Creation does 
not have to be done on a server that hosts the observed resource.  
Exercise: why might this be desirable?)

2) Sit back and wait for updates.  (Notifications don't need to be sent 
by the owner of the observed resource.  Exercise: why might this be 
desirable?)

3) Delete the subscription resource when the subscription is no longer 
desired.

Sure there are details to be worked out, but this seems more RESTful 
(and clean and harmonious) than having subscriptions (aka state, at 
whatever layer) created and destroyed as a side effect of requesting 
transfer of a (representation of a) resource.

Something for CoAPbis to consider, or not.

Peter

---

From: "Victor Blake" <[email-masked]>
Date: Sun, 9 Mar 2014 17:08:57 -0400

Well stated Peter. I agree, it's a choice to "create a resource representing
a subscription" and thereafter treat it as such.

-Victor

-----Original Message-----
From: Peter A. Bigot [mailto:[email-masked]] 
Sent: Saturday, March 08, 2014 7:20 PM
To: [email-masked]
Subject: Re: [core] Observe Cancellation: The outcome

On 03/08/2014 11:15 AM, Carsten Bormann wrote:
> On 08 Mar 2014, at 16:10, FOSSATI, Thomas (Thomas)
<[email-masked]> wrote:
> There is no "reuse".
> At the level of the REST model, there is no change: These representations
are cacheable, they can be operated on by chains of proxies ("layered
system") only some of which make use of Observe, maintaining a uniform
interface, and so on.
> Setting up an Observation relationship asks for future representations as
well; renewing checks and possible re-establishes it, canceling ends the
indication of interest.
> But this is not application state: This is entirely an optimization that
saves polling (or, long-polling, which goes much further in the way of
bending the REST principles).
> Saying this is "not RESTful" is tantamount to claiming HTTP is not RESTful
because it involves setting up TCP state.

Agreed: There is no state at the HTTP (request/response transaction) layer;
it's present at the TCP (data transport) layer, which is conceptually
decoupled from HTTP in a RESTful system (e.g., HTTP/SMTP).

In CoAP, the state that's being created for -observe is being created and
destroyed as a side-effect of a GET request (transaction), and is identified
through a transaction-layer concept (Token).  So we can say there's no
inter-transaction state preserved in an -observe operation because the
transaction simply hasn't completed until something causes it to stop; all
those requests/responses over long periods are the moral equivalent of IP
packets, and the state required to support them the moral equivalent of TCP
state.

> The Observation relationship state is not modeled as a resource, because
it really isn't one.

1) Create a resource representing a subscription from a client to a server,
containing the URI of the resource to be observed and a URI to which changes
to the observed resource should be sent.  (Creation does not have to be done
on a server that hosts the observed resource.  
Exercise: why might this be desirable?)

2) Sit back and wait for updates.  (Notifications don't need to be sent by
the owner of the observed resource.  Exercise: why might this be
desirable?)

Sure there are details to be worked out, but this seems more RESTful (and
clean and harmonious) than having subscriptions (aka state, at whatever
layer) created and destroyed as a side effect of requesting transfer of a
(representation of a) resource.

Peter

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Mon, 10 Mar 2014 10:06:57 +0000

Hi Carsten.

>bending the REST principles).

Current -observe design has been stretching GET’s safe-ness to the
point I’m not sure we can consider it a safe method anymore.
But I guess we can debate endlessly about this.

>Saying this is “not RESTful” is tantamount to claiming HTTP is not
>RESTful because it involves setting up TCP state.

Well, it looks like you're flipping the layers here ;-)  But again, this
kind of considerations tends to be very subjective.

What is objective is the consensus of the room, which was definitely in
favour of the GET+option proposal, and the 99.4% of interoperability in
the plug test session -- i.e. "rough consensus and running code” at
its best.

The sooner we move on to deliver -observe to IESG, the sooner we can
restart discussing if/how to enhance its design.

Cheers

---

From: Zach Shelby <[email-masked]>
Date: Mon, 10 Mar 2014 09:42:07 -0700

> restart discussing if/how to enhance its design.

Yep, the consensus was clear, and it worked very well for CoAP implementations. Looking forward to shipping this to the IESG.

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 11 Mar 2014 21:35:50 +0100

Within the class of solutions we agreed on (overloading the GET
method), the simplest solution is a GET request without Observe option
and with the token in use. How bad is its drawback (having to check
for a potential observation to be canceled on every GET request)
really?

Klaus

---

From: Zach Shelby <[email-masked]>
Date: Tue, 11 Mar 2014 13:46:38 -0700

> for a potential observation to be canceled on every GET request)

At least for our implementation the effect is minimal. We only need to a cancellation check when the Observe option is present, which we need to do anyways for renewal.

Zach Shelby
Director of Technology

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 11 Mar 2014 22:13:39 +0100

I'm asking about the alternative solution where the Observe option is *not*
present. How bad is the impact of the cancellation check there? In my
implementation, it's basically free, because I'm performing a similar check
anyway.

Klaus

On Tuesday, 11 March 2014, Zach Shelby <[email-masked]> wrote:

> On Mar 11, 2014, at 1:35 PM, Klaus Hartke <[email-masked] <javascript:;>>
> wrote:
>
> At least for our implementation the effect is minimal. We only need to a
> cancellation check when the Observe option is present, which we need to do
> anyways for renewal.
>
> Zach Shelby
> Director of Technology
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
>
> _______________________________________________
> core mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/core
>

---

From: "weigengyu" <[email-masked]>
Date: Wed, 12 Mar 2014 11:14:39 +0800

Hi Klaus and all, 

To define “the Observe option is *not* present” means “Cancellation” is not good choice, I think. 

Why not to make the sematics clear.  
It seems that Get with Observe option of BEING intereted can do subscription, and Get with Observe option of  NOT interested will do cancellation.  

I think that the CoAP observation operatoins are much like operations of subcription/unsubscription of IETF mailing list.

Regards, 

Gengyu 

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
From: Klaus Hartke 
Sent: Wednesday, March 12, 2014 5:13 AM
To: Zach Shelby 
Cc: mailto:[email-masked] ; Klaus Hartke 
Subject: Re: [core] Observe Cancellation: The outcome

I'm asking about the alternative solution where the Observe option is *not* present. How bad is the impact of the cancellation check there? In my implementation, it's basically free, because I'm performing a similar check anyway. 

Klaus

  Zach Shelby
  Director of Technology

  [email-masked]

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

---

From: Likepeng <[email-masked]>
Date: Wed, 12 Mar 2014 06:43:24 +0000

>To define “the Observe option is *not* present” means “Cancellation” is not good choice, I think.

Agree, that is where the issue (having to check for a potential observation to be canceled on every GET request) coming from.

>Why not to make the semantics clear.
>It seems that Get with Observe option of BEING interested can do subscription, and Get with Observe option of  NOT interested will do cancellation.

Agree to make it clear, that is. Give “Observe” option a value.

Kind Regards
Kepeng

发件人: core [mailto:[email-masked]] 代表 weigengyu
发送时间: 2014年3月12日 11:15
收件人: Klaus Hartke; Zach Shelby
抄送: [email-masked]
主题: Re: [core] Observe Cancellation: The outcome

Hi Klaus and all,

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
From: Klaus Hartke<mailto:[email-masked]>
Sent: Wednesday, March 12, 2014 5:13 AM
To: Zach Shelby<mailto:[email-masked]>
Cc: mailto:[email-masked] ; Klaus Hartke<mailto:[email-masked]>
Subject: Re: [core] Observe Cancellation: The outcome

Klaus

On Tuesday, 11 March 2014, Zach Shelby <[email-masked]<mailto:[email-masked]>> wrote:

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com<http://www.arm.com>
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/<http://fi.linkedin.com/in/zachshelby/>

_______________________________________________
core mailing list
[email-masked]<javascript:;>
https://www.ietf.org/mailman/listinfo/core
________________________________
_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Robert Cragie <[email-masked]>
Date: Wed, 12 Mar 2014 08:35:09 +0000

+! - the semantics should be clear. The absence of the option does not
imply cancellation in the actual message itself.

Robert

On 12 March 2014 06:43, Likepeng <[email-masked]> wrote:

> Agree, that is where the issue (having to check for a potential
> observation to be canceled on every GET request) coming from.
>
>
>
> >It seems that Get with Observe option of BEING interested can do
> subscription, and Get with Observe option of  NOT interested will do
> cancellation.
>
>
>
> *发件人:* core [mailto:[email-masked]] *代表 *weigengyu
> *发送时间:* 2014年3月12日 11:15
> *收件人:* Klaus Hartke; Zach Shelby
> *抄送:* [email-masked]
> *主题:* Re: [core] Observe Cancellation: The outcome
>
>
>
> Hi Klaus and all,
>
>
>
> It seems that Get with Observe option of BEING intereted can do
> subscription, and Get with Observe option of  NOT interested will do
> cancellation.
>
>
>
> I think that the CoAP observation operatoins are much like operations of
> subcription/unsubscription of IETF mailing list.
>
>
>
> Regards,
>
>
>
> Gengyu
>
>
>
> *From:* Klaus Hartke <[email-masked]>
>
> *Sent:* Wednesday, March 12, 2014 5:13 AM
>
> *To:* Zach Shelby <[email-masked]>
>
> *Cc:* mailto:[email-masked] <[email-masked]> ; Klaus Hartke <[email-masked]>
>
> *Subject:* Re: [core] Observe Cancellation: The outcome
>
>
>
> I'm asking about the alternative solution where the Observe option is
> *not* present. How bad is the impact of the cancellation check there? In my
>   ------------------------------
>