Subject: [core] Observe Cancellation

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 4 Mar 2014 15:21:41 +0000

Dear list

I want to start the discussion about what to do about Observe cancellation. Today's session showed that we have two options to finish -observe: (i) fix something by the end of the week and (ii) eject the cancellation mechanism and deal with it in a separate draft.

To help finding consensus by the end of this week, I started a pro/con list for the possible solutions we have. Please comment, amend, etc., especially when you are an implementer!

RST with Last Notification MID
=======================
PRO
+ No re-use of active Token
+ No representation on cancel
CON
- Needs special rule to keep MIDs beyond lifetime
-- Not available over alternative transports

I think this does not work because of the alternative transports.

PUT/POST/DELETE with Observe Option
==============================
PRO
+ It is not a GET
CON
-- Observe is elective and unsafe methods might corrupt the resource state

I think it is a really bad idea to overload an unsafe method for this.

GET without Observe Option
======================
PRO
+ Modular design based on GET
+ Already tested
CON
- Transmission of representation despite disinterest (including caches)
- Re-use of active Token
- Needs special rule to keep request the same (similar to re-registration)

The GET without Observe option allows many different implementation strategies: first dividing into requests or responses (for the hybrid CoAP client-and-server implementations for LWM2M), first delivering a request to its resource before further inspection (Observe support could be added within a resource handler implementation), having a clean processing pipeline, ....

7.xx Control Messages
=================
PRO
+ No re-use of active Token (as request)
+ No representation on cancel
CON
- Still re-use of active Token for re-registration
- Control message class brings the danger of mutation into a very unRESTful protocol
- New class at late state (why is CoAP ping not a control message?)
- Conflict with DTLS message detection (if kept at end of 7.xx)
- Management of remote Tokens (different namespaces...) or hooks that shortcut the protocol control flow

The control message cancellation is also useful for separate responses as well as the liveliness checks of the full liveliness draft. However, this goes beyond Observe. Observe without active cancellation still works and LWM2M could include the liveliness module to have the required active cancellation.

Hoping for your input
Matthias

---

From: Likepeng <[email-masked]>
Date: Tue, 4 Mar 2014 16:42:38 +0000

>GET without Observe Option

I prefer this option. We implemented this mechanism, and it works fine.

>Today's session showed that we have two options to finish -observe: (i) fix something by the end of the week and (ii) eject the cancellation mechanism and deal with it in a separate draft.

I prefer to fix it by the end of this week. It is a small update, and not necessarily to be a separate draft. Also it is better to have the mechanism together with the observe draft, to have the whole solution.

Kind Regards
Kepeng

-----邮件原件-----
发件人: core [mailto:[email-masked]] 代表 Kovatsch Matthias
发送时间: 2014年3月4日 15:22
收件人: [email-masked]
抄送: [email-masked]; 'Klaus Hartke ([email-masked])'
主题: [core] Observe Cancellation

Dear list

7.xx Control Messages
=================
PRO
+ No re-use of active Token (as request) No representation on cancel
CON

Hoping for your input
Matthias

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

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 4 Mar 2014 17:54:25 +0000

MIDs have a lifetime (basically for deduplication, 247s...). To avoid implementations forgetting due to a clean-up, we would need to define a longer lifetime for notification MID.

Anyhow, there are no RSTs when used over WebSockets, TCP, or SMS and we do not want to close the whole connection only to cancel a specific Observe relationship.

-------- Original message --------
From: Szymon Sasin
Date:2014/03/04 17:42 (GMT+00:00)
To: Kovatsch Matthias ,[email-masked]
Cc: "'Klaus Hartke ([email-masked])'"
Subject: RE: Observe Cancellation

> RST with Last Notification MID
+1

What do you mean that it needs special rule to keep MIDs beyond lifetime?

--
Szymon Sasin
Staff SW Engineer
IoT BU
ARM Ltd.

________________________________________
From: Kovatsch  Matthias [[email-masked]]
Sent: Tuesday, March 04, 2014 5:21 PM
To: [email-masked]
Cc: 'Klaus Hartke ([email-masked])'; Szymon Sasin
Subject: Observe Cancellation

Dear list

7.xx Control Messages
=================
PRO

Hoping for your input
Matthias

-- 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: Bert Greevenbosch <[email-masked]>
Date: Wed, 5 Mar 2014 16:10:30 +0000

Hi Matthias,

I prefer "GET without Observe Option" (using the same token).

Works fine, and doesn't give issues to non-supporting devices.

I don't really worry about the token-reuse issue, especially since the token is related to that observe transaction anyway.

Best regards,
Bert

________________________________________
From: core [[email-masked]] on behalf of Kovatsch  Matthias [[email-masked]]
Sent: 04 March 2014 23:21
To: [email-masked]
Cc: [email-masked]; 'Klaus Hartke ([email-masked])'
Subject: [core] Observe Cancellation

Dear list

7.xx Control Messages
=================
PRO

Hoping for your input
Matthias

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 6 Mar 2014 08:22:00 +0000

Looking at the pros and cons of the solutions the "GET without Observe Option" comes out  best, avoiding "--" cons and having the least number of "-" cons.
Can people confirm that the list of pros and cons is complete? (i.e. no items have been overlooked)

The issue "- Control message class brings the danger of mutation into a very unRESTful protocol" would also hold for the "GET without Observe" option or not? Since we're using GET then for its side-effect and not to get the resource content. And besides, isn't IETF/CoRE in control of the codes allocation so the amount of unRESTful-ness is under our control.

The issue "- Conflict with DTLS message detection (if kept at end of 7.xx)" seems not a problem if something else than 7.31 is chosen, or not? (Why not 7.01?)

The issue "- Management of remote Tokens (different namespaces...) or hooks that shortcut the protocol control flow" I don't fully understand. (Was that previously discussed?)

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Wednesday, March 05, 2014 17:11
To: Kovatsch Matthias; [email-masked]
Cc: [email-masked]; 'Klaus Hartke ([email-masked])'
Subject: Re: [core] Observe Cancellation

Hi Matthias,

Best regards,
Bert

Dear list

7.xx Control Messages
=================
PRO

Hoping for your input
Matthias

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2014 08:29:16 +0000

On 06 Mar 2014, at 08:22, Dijk, Esko <[email-masked]> wrote:

> Since we're using GET then for its side-effect and not to get the resource content. 

I may be misreading this:
You mean we should define this in such a way that the GET isn’t actually executed if it on the token of an existing observation relationship?  That would be ugly indeed.

Grüße, Carsten

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 06 Mar 2014 09:02:46 +0000

Carsten Bormann <[email-masked]> writes:

> You mean we should define this in such a way that the GET isn’t
> actually executed if it on the token of an existing observation
> relationship?  That would be ugly indeed.

A client could use the No-Response option to overcome this.

>From my point of view, the "GET without Observe" is the most ugly to
implement. For RST and 7.xx, the message can be handled automatically at
the message layer while a GET must be passed on to the application. 

The drawbacks of 7.xx are there, no question, but from an implementation
perspective, this seems to be the easiest to implement as it is treated
similar to RST.

Gruesse
Olaf

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 6 Mar 2014 09:03:18 +0000

No, I just meant that in the "GET without Observe" solution we are using the on its own very RESTful GET request only for its side-effect: which is cancelling an existing Observe relationship i.e. to delete some binding. That sounds to me un-RESTful as well.   The optimal RESTful way would be like e.g. used in Resource Directory; first POST somewhere to create a relationship, then the server returns a new resource Location-URI like /relation/1234 which the client may DELETE at a future point in time to stop the relationship. But perhaps that's too heavy-weight for the purpose, and leads to the question of where to POST to etc.

In summary, also here I see some "danger of mutation into a very unRESTful protocol"

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, March 06, 2014 09:29
To: Dijk, Esko
Cc: Bert Greevenbosch; [email-masked]
Subject: Re: [core] Observe Cancellation

I may be misreading this:
You mean we should define this in such a way that the GET isn't actually executed if it on the token of an existing observation relationship?  That would be ugly indeed.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 6 Mar 2014 10:34:46 +0100

Hi Esko!

Esko Dijk wrote:

> Looking at the pros and cons of the solutions the "GET without Observe
> Option" comes out  best, avoiding "--" cons and having the least number of
> "-" cons.

Matthias and I discussed the list before he posted it, so it's these are
the issues we could come up with. The intention of the mail is to fully
understand each alternative by discussing the pros and cons and finding
more pros and cons, not to start a vote on picking an alternative.

The issue "- Control message class brings the danger of mutation into a
> very unRESTful protocol" would also hold for the "GET without Observe"
> option or not? Since we're using GET then for its side-effect and not to
> get the resource content. And besides, isn't IETF/CoRE in control of the
> codes allocation so the amount of unRESTful-ness is under our control.

Since REST is about single request/single response interactions, having
interactions where a single request leads to a stream of responses makes
the protocol strictly speaking unRESTful. But since resource observation
otherwise blends in with REST perfectly (transfer of resource state
representations, support for intermediaries and caches, etc.), it can be
thought of as some kind of Extended REST. The danger is, once we have lots
of unassigned control codes available, that people could want to use them
for things outside the Extended REST scope ("unExtendedRESTful").

In Extended REST, there are two situations where we want a new kind of
interaction besides requests (which target resources) and responses (which
target requests). These interactions are new because they target ongoing
observations: when the client has not received a notification for a
while and wants to check whether the server is still aware of the
observation; and when the client is no longer interested in the observation
and wants the server to cancel the observation.

The question is how to express these new interactions in our messages.
There generally two possible strategies: introduce new protocol elements
for them, or overloading existing protocol elements with additional
semantics. For the single request/multiple response interaction, we chose
to overload the GET method, because it provides representation-retrieval
semantics and nicely falls back to polling if the feature is not supported.
For the liveliness check, we chose to overload the GET method as well,
because we didn't want to introduce a new protocol element, and the client
likely wants to re-register after the check anyway. Though this gave us a
headache about token reuse and request matching with some unspecified
behavior now in the protocol. For cancellation, the pattern breaks down
now, because cancellation is the very case where the client does not want a
current representation anymore and the GET method always gives the client a
current representation.

The issue "- Conflict with DTLS message detection (if kept at end of 7.xx)"
> seems not a problem if something else than 7.31 is chosen, or not? (Why not
> 7.01?)

This is not really an issue if we reserve some codes for current an future
versions of DTLS (assuming that future versions still have the major
version in the second byte). DTLS 1.x is code 7.30, DTLS 2.x is code 7.29,
etc. We could reserve codes 7.20 to 7.30 for DTLS, which leaves codes 7.00
to 7.19 as well as 7.31 to our disposal. I do not expect any other use case
than the liveliness check and cancellation, so the allocation of the entire
7.xx range could be seen as waste or lead people to look for more control
codes.

The issue "- Management of remote Tokens (different namespaces...) or hooks
> that shortcut the protocol control flow" I don't fully understand. (Was
> that previously discussed?)
>

The issue here is mostly that there are so many implementations already,
which all assume that there are no interactions besides requests and
(multiple) responses (with some small hack to support re-registrations).
Whichever solution for cancellation we pick, there will always be an
implementation that will require a significant rewrite. In the case of the
7.31 control code, it's Matthias' implementation :-)

Best regards,
Klaus

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 06 Mar 2014 09:54:24 +0000

Klaus,

you may just have convinced me that the cleanest solution would be to
take a huge step back and make observe soft-state again (let the
observer tell the resource server how long it wants the observation
relationship to persist, and the resource server answer with some value
that tells the planned expiry time of that relationship, which may or
may not be smaller than the requested expiry time.)

I am fully aware that this has a lot of practical issues, starting with
the notion of real time missing on some platforms. The benefit is that
this makes the protocol much cleaner as notifications now can tell the
observer how long the resource server thinks the relationship to
persist. The burden would be on the client to re-establish the
observation relationship, let it expire or clear it by requesting an
expiration time of zero.

Gruesse
Olaf

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 6 Mar 2014 11:10:36 +0100

Hi Bert!

Bert Greevenbosch wrote:

> I don't really worry about the token-reuse issue, especially since the
> token is related to that observe transaction anyway.
>

The issue here is more that cancellation by itself is a very simple thing
really: one hop tells the next hop to stop, done. However, the usage of the
GET method naturally drags in the whole semantics of resource
representation retrieval: in addition to simply updating some internal data
structure, the next hop now must acquire a current representation of the
target resource to return. This may involve just checking the local cache,
but may also involve requesting the representation from the next hop, which
may have to acquire it from the next hop, and so on. This may involve
waiting for sleepy devices to wake up, powering up radios, establishing
secure connections -- all of which are expensive operations.

It seems that cancellation is a fairly frequent interaction in some
scenarios, i.e., there are scenarios where observations are short-lived and
predominantly ended by proactive cancellation. I don't know if the cost of
a full GET request every time is acceptable here.

Best regards,
Klaus

---

From: "Peter A. Bigot" <[email-masked]>
Date: Thu, 06 Mar 2014 06:47:52 -0600

+1. (+100 if it were possible; what Esko proposes is exactly what I had 
in mind over three years ago.)

I have never been comfortable with -observe, and never felt the WG was 
particularly interested in a RESTful approach to the underlying 
problem.  My last attempt at working towards such a solution produced 
http://www.ietf.org/mail-archive/web/core/current/msg00970.html which 
pretty much told me I was wasting my time.

Last fall I tried to implement CoAP from the specification; 
http://pabigot.github.io/coapy/ has the result to the point where I gave 
up.  You can see where it started to go off the rails in the 
architectural analysis at 
http://pabigot.github.io/coapy/domain.html#operations, where I tried to 
formalize the notion of cancellation at the message level.  Without a 
robust solution to that, cancellation at the transaction level becomes 
even more messy.

Regardless of past history, transaction termination and cancellation are 
foundational concepts, and a solution that only works for -observe is, 
in my opinion, a mistake.

Also regardless of where things are today, it is long past time to ship 
CoAP and its companion capabilities (-observe, -block, etc) so people 
who have not been intimately involved in its evolution can determine 
whether it meets their needs and work on CoAPbis can start, informed by 
real-world experience.

Peter

---

From: "Thoma, Matthias" <[email-masked]>
Date: Thu, 6 Mar 2014 13:49:05 +0000

Hi,

to add one more implementator point of view: 

What we are currently using is also the "get without observe" option, but with an additional optional no-response option (like it has been proposed here) to save some energy (otherwise the sensor would have to gather information which might just been thrown away at the receiver side). The RST also had something appealing, but as it supported by alternative transport  (*) I can understand why people think it is a no-go.  Generally, I agree with Peter and Esko that the current way CoAP-observe is working is not very RESTful, but on the other hand, a more RESTful solution might already be too resource intensive for very constrained devices. 

Furthermore, why not giving people a choice? I also see some valid points for the RST+MID in CoAP over UDP, when you are in a very constrained device as the parsing complexity is way smaller and you can cancel an observer by examining the 4-byte header only. The problem with clean but resource hungry or too complex solutions (which might work with every transport-layer protocol) is that people might start just ignoring it, looking for less energy/computation/memory whatever-consuming ways of doing things.  I wouldn't prematurely give up on nice  elegant  resource-saving solutions, even if they are transport layer specific.  Additionally, to a one works-for-all solution, of course.

(*) Looking into the websockets alternative transport, I got the feeling that the unlayered "mixing" of concepts (transport layer, application layer) in CoAP is, while maybe justified from a constraintness point of view, is  very unfortunate from a general engineering point of view.  After all, even the header of the protocol changed so it is not as easy as it could be to move from one transport layer (CoAP over UDP) to another (CoAP over websockets) as it could be. 

Best,
  Matthias

-- 
SAP (Switzerland) Inc. 
BIT PA&TS 
T   +41 58 871 7843 | mailto: [email-masked]
http://www.sap.com

Please consider to send me encrypted mail: http://keys.sap.com

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Peter A. Bigot
Sent: Donnerstag, 6. März 2014 13:48
To: [email-masked]
Subject: Re: [core] Observe Cancellation

Peter

---

From: Floris Van den Abeele <[email-masked]>
Date: Thu, 06 Mar 2014 15:06:25 +0100

To clarify: the "Still re-use of active Token for re-registration" CON
applies to all alternatives, right (as it is only mentioned here)?

To comment on the no-response option alternative, is there an
acknowledge from the server to the observer that the observer was
removed from the list? In case the cancellation request was sent as a
CON message, this cancellation ack could coincide with the message ACK
(i.e. only the resource representation is elided from the response)?
Going through draft-tcs-coap-no-response-option-05, this was not clear
to me as it is ignored for CON messages.

Floris

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 6 Mar 2014 14:07:15 +0000

>In summary, also here I see some "danger of mutation into a very

100% agree with Esko’s concern.

I share the idea that the fundamental problem here is that the Observe
state at the server is not modelled as a resource, and thus it can’t be
controlled in a RESTful way.  That’s it.

As I’ve already said, I’d really prefer to use a control signal then
overriding the semantics of a method as basic as GET.

On the other hand I’m also concerned by the changes to the protocol state
machine implied by a new control signal as it’s been highlighted by Bert,
Matthias, and Zach (among the others), and the fact that these changes are
going to have a big impact on existing implementations.

So, my humble suggestion is that for the time being we accept that we have
already “dangerously mutated into a very unRESTful protocol” and just try
to work around Observe's un-RESTful-ness in the simplest possible way.

The quicker we move -observe to LC, the earlier we can start re-thinking
it (based on what we’ve learned) and try to get it perfectly right this
time.

Cheers

PS: I don’t want this email sounds derogatory towards Klaus who I think
has done a super super job with this draft.

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 6 Mar 2014 14:31:08 +0000

Hi Klaus,

Thank you for your feedback.

True, requesting the payload may unnecessarily take energy. The sleep issue is only relevant in case of a proxy handling the observe relationship (which indeed may quite frequently be the case), since if there was no proxy the client had to wait until the server waked up for any message, including observe cancellation.

For servers that support observe and thus the observe option, we could also include something in the observe option payload of the request, e.g. a code for cancel. That would not resolve the issue with the non-supporting server though. Such a device wouldn't generate an observation relationship on receiving the observation registration request, but send a response with a payload, and would behave similarly when receiving the observation cancellation request.

What do servers do when they receive unknown message codes? Would the message be discarded, or will the server send a 4.00 "bad request" response? It seems to be undefined right now, but whatever it is, it would happen when non-supporting servers receive a 7.31 code.

Notice that section 5.8 says:

"A
   request with an unrecognized or unsupported Method Code MUST generate
   a 4.05 (Method Not Allowed) piggy-backed response.
"

So that could argue for e.g. a 0.05 code (note that GET is 0.01, POST 0.02 etc.) as an alternative to 7.31. At least it would fit the request/response architecture then, and there is clearly defined behaviour of non-supporting servers. A new method "CANCEL"? Could be useful for e.g. cancelling block PUT transactions too (informing the server to discard whatever it has already received). Just thinking aloud here, not really proposing it as a solution at this time.

Best regards,

Bert

________________________________
From: Klaus Hartke [[email-masked]]
Sent: 06 March 2014 18:10
To: Bert Greevenbosch
Cc: Kovatsch Matthias; [email-masked]; [email-masked]; Klaus Hartke ([email-masked])
Subject: Re: [core] Observe Cancellation

Hi Bert!

Bert Greevenbosch wrote:

The issue here is more that cancellation by itself is a very simple thing really: one hop tells the next hop to stop, done. However, the usage of the GET method naturally drags in the whole semantics of resource representation retrieval: in addition to simply updating some internal data structure, the next hop now must acquire a current representation of the target resource to return. This may involve just checking the local cache, but may also involve requesting the representation from the next hop, which may have to acquire it from the next hop, and so on. This may involve waiting for sleepy devices to wake up, powering up radios, establishing secure connections -- all of which are expensive operations.

It seems that cancellation is a fairly frequent interaction in some scenarios, i.e., there are scenarios where observations are short-lived and predominantly ended by proactive cancellation. I don't know if the cost of a full GET request every time is acceptable here.

Best regards,
Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2014 14:32:00 +0000

> Furthermore, why not giving people a choice? I also see some valid points for the RST+MID in CoAP over UDP, when you are in a very constrained device as the parsing complexity is way smaller and yo…

RST is great for reactive cancellation (at least if the message layer for your transport has a RST) and is not going away.
Reactive cancellation is needed if you receive a notification that you forget you (or your previous incarnation) ordered, and RST is the right way to handle this case.
(Note that this is less applicable on connection-oriented transports, which are likely to fate-share with the observation relationships.)

The current discussion is about proactive cancellation: You have set up an observation and want to get rid of it at a particular point in time, without necessarily having a fresh notification in hand.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2014 14:31:41 +0000

> controlled in a RESTful way.  That’s it.

The TCP connections that carry HTTP also cannot be modeled as a resource.
This doesn’t seem to make HTTP “unrestful”.

We tried to skip defining a teardown message for long running requests such as observation relationships, and that may have been a mistake.
Klaus wants to fix this outright, which is relatively simple as the token provides a good handle to do that.
The other proposals will allow us to live without such a message for now, by going through the ordinary request code path and detecting the cancellation based on some option matching.

I don’t have a strong opinion here, except that I am in a plugtest in less than 24 hours and we want to run tests for whatever we decide...

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2014 14:41:45 +0000

On 06 Mar 2014, at 14:31, Bert Greevenbosch <[email-masked]> wrote:

> So that could argue for e.g. a 0.05 code (note that GET is 0.01, POST 0.02 etc.) as an alternative to 7.31. 

Pro: The rule which side is the owner of the token space stays simple (0.xx = my space, y.xx = your space).
Cons:
— Cancel isn’t really a request on a resource, so this is still confusing.
— The method code space is relatively small.

If we are going this way, we should probably use 0.31 to clearly separate request method codes from this new kind of other method codes like cancel.
From an implementation point of view, all other issues cited with retrofitting 7.31 cancel remain.

Grüße, Carsten

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 6 Mar 2014 14:48:45 +0000

On 06/03/2014 14:31, "Carsten Bormann" <[email-masked]> wrote:
>On 06 Mar 2014, at 14:07, FOSSATI, Thomas (Thomas)
><[email-masked]> wrote:
>

But they were wise enough not to introduce any explicit "resource
observation" concept there :-)

For the record: Roy Fielding’s Waka [*], an experimental replacement for
HTTP/1.x, introduced a MONITOR method which has the exact semantics as
Observe.  I don’t know if and how that evolved though.

[*] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf

---

From: "Thoma, Matthias" <[email-masked]>
Date: Thu, 6 Mar 2014 14:59:59 +0000

> The current discussion is about proactive cancellation: You have set up an observation and want to get rid of it at a particular point in time, without 
> necessarily having a fresh notification in hand.

I didn't want to write  anything about reactive cancellation.  I completely understand that part. But if it is already 90% there, it is nice and elegant, resource-saving and relatively  easy to implement  why not (optionally) also use it for active cancellation as well. Other, future, CoAP over something, might have even nicer solutions at equally low levels which save some resources.  Just wanted to make the point, that apart from one-fits-all solutions, given the domain "constraint devices" considering further transport-layer active cancellation mechanisms might still be worth being considered. If this is considered a good thing or a bad thing depends on your specific use-cases, of course, and on what one considers "resource constrained". An equally nice higher level  solution is, of course, even better. 

If the GET + non-observe option is considered the right solution, then I can tell you from our implementation: It is reliable and works well, but needs more computation time and energy, than the RST solution.  We didn't had any problems with it.

The cleanest solution (but not the best in terms of energy or computation) would be to go the ReSTFul way as suggest by others here, but I assume there were good reasons not to do that in the first place.

- Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2014 15:14:42 +0000

On 06 Mar 2014, at 14:59, Thoma, Matthias <[email-masked]> wrote:

> why not (optionally) also use it for active cancellation as well. 

reactive works so well because the server has active state (the context of the notification message being delivered) while the RST arrives.
(In some implementations, that is already a stretch for NON notifications, which is why RST handling is not mandatory there.)
If there has been no recent notification, you don’t have a message-ID to key the RST to, so RST cannot be used for proactive cancellation.
The closest one can do is key on the token, which is exactly what Klaus’ proposal is about.
However, some implementations on the server side key on the request parameters, so these have to match to get even close to the place where the observation state is managed.
(This is not a problem for an observation renewal, which has all those request parameters, and not for the “superfluous GET” approach.)

Grüße, Carsten

---

From: "Thoma, Matthias" <[email-masked]>
Date: Thu, 6 Mar 2014 15:26:02 +0000

> If there has been no recent notification, you don't have a message-ID to key the RST to, so RST cannot be used for proactive cancellation.

The original idea said "RST with Last Notification MID", so there is the last notification id. When I was saying active RST I always referred to that idea and something I just made up. My intention was to add some more points on the pro-side, like the fact that it needs less processing power than a "GET without Observe Option" as the resource (as in energy or computing power) saving aspect was not on the pro/con list of any item and I would consider that important in some constrained environments. Furthermore more compact implementations would be possible. Didn't want to start a religious thread... :-)

Best,
  Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2014 16:08:29 +0000

On 06 Mar 2014, at 15:26, Thoma, Matthias <[email-masked]> wrote:

> "RST with Last Notification MID"

The main problem here is that this message ID may have been reused since.
Enabling this extended usage of message-IDs would require reserving the last message ID used on the server side for each observed resource.
This requires new message-ID handling techniques (can’t just garbage-collect after EXCHANGE_LIFETIME).
(There also is the obvious limit to the number of observation relationships, but I don’t think one is likely to hit that.)
You wouldn’t always be able to cancel an observation relationship that hasn’t had its first notification beyond the initial response (which is likely to be piggy-backed, hence does not have a server-side message-ID).

Grüße, Carsten

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 6 Mar 2014 17:06:25 +0000

On 06/03/2014 14:41, "Carsten Bormann" <[email-masked]> wrote:
>If we are going this way, we should probably use 0.31 to clearly separate
>request method codes from this new kind of other method codes like cancel.

This is possibly the lesser of two evils.

And btw I support the idea of “informally" partitioning the 0-31 space
into 2: lower for genuine requests, higher for control codes. (Too bad we
used 0 for ping already…)

>retrofitting 7.31 cancel remain.

Actually, this may not be as terrible as it sounds.  You surely need to
dispatch the “explicit cancellation” signal from the client to the
"teardown observation state” function block.  Expressing the “explicit
cancellation” in a way or another makes that much difference?  Especially
if we move it to the 1..31 space so that an hybrid implementation can
forward it to the right processing pipeline upfront.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 6 Mar 2014 10:03:13 -0800

"GET without Observe Option (using the same token)" would also be my preference.

Zach

> I don't really worry about the token-reuse issue, especially since the token is related to that observe transaction anyway.

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/

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 6 Mar 2014 19:39:07 +0000

Hi all,

Klaus, Thomas, Kepeng and I had some discussion on this today.

Some extra things that came up in this discussion and may need consideration:

- Using "GET without observe" to cancel an observation relationship requires executing code related to observe for every GET request, even if the client has never subscribed to the resource.
- A response may not be required, since it is enough for the observation to be cancelled on the server side, and the client may not require knowledge on the result of the deletion.*

*) when the server receives a "cancel observation", there two possibilities:
  - the server knows the token, and deletes the related observationship
  - the related observation relationship does not exist
In both cases, the result is that the observation relationship does not exist on the server after receipt of the message.

Best regards,
Bert

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 6 Mar 2014 22:17:50 +0000

On 06/03/2014 19:39, "Bert Greevenbosch" <[email-masked]>
wrote:
>- Using "GET without observe" to cancel an observation relationship
>requires executing code related to observe for every GET request, even if
>the client has never subscribed to the resource.
>- A response may not be required, since it is enough for the observation
>to be cancelled on the server side, and the client may not require
>knowledge on the result of the deletion.*
>
>In both cases, the result is that the observation relationship does not
>exist on the server after receipt of the message.

Another point that we’ve cleared is that using a code for the cancellation
in the 5-31 space doesn’t look quite right:

  "A CoAP request consists of the method to be applied to the resource”

The problem is that the cancellation does not apply to a resource, but
rather to the state that encodes the relationship between the client, the
server, and a resource.

---

From: "Victor Blake" <[email-masked]>
Date: Fri, 7 Mar 2014 08:08:12 -0500

...And using a code isn't exactly RESTful.

-Victor

-----Original Message-----
From: FOSSATI, Thomas (Thomas) [mailto:[email-masked]] 
Sent: Thursday, March 06, 2014 5:18 PM
To: Bert Greevenbosch; [email-masked] WG
Subject: Re: [core] Observe Cancellation

On 06/03/2014 19:39, "Bert Greevenbosch" <[email-masked]>
wrote:
>requires executing code related to observe for every GET request, even 
>if the client has never subscribed to the resource.
>- A response may not be required, since it is enough for the 
>observation to be cancelled on the server side, and the client may not 
>require knowledge on the result of the deletion.*
>
>  - the related observation relationship does not exist In both cases, 
>the result is that the observation relationship does not exist on the 
>server after receipt of the message.

Another point that we’ve cleared is that using a code for the cancellation in the 5-31 space doesn’t look quite right:

The problem is that the cancellation does not apply to a resource, but rather to the state that encodes the relationship between the client, the server, and a resource.

---

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

> ...And using a code isn't exactly RESTful.

The “code” is just the second byte of the message, which, depending on content, is interpreted as an empty message indicator (0.00), a method (0.xx), or a response code (y.xx).

What is not RESTful about this method of encoding?

Grüße, Carsten

---

From: "Victor Blake" <[email-masked]>
Date: Sat, 8 Mar 2014 11:17:34 -0500

Perhaps REST in general, but RESTful implies that the state is shown in the
locator and further (I understand it doesn't require this, but again -- a
distinguishing characteristic of the RESTful style) human readable format so
instead of for example coded data, you might have /param_name=cancel or =yes
or =y or =no or =n in the case of a positive/negative state change.

-Victor

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Friday, March 07, 2014 11:31 AM
To: Victor Blake
Cc: FOSSATI, Thomas (Thomas); Bert Greevenbosch; [email-masked]
Subject: Re: [core] Observe Cancellation

> ...And using a code isn't exactly RESTful.

The “code” is just the second byte of the message, which, depending on
content, is interpreted as an empty message indicator (0.00), a method
(0.xx), or a response code (y.xx).

Grüße, Carsten