Subject: Re: [core] Observe Cancellation

From: "weigengyu" <[email-masked]>
Date: Fri, 7 Mar 2014 12:27:55 +0800

HI all,

My suggestion is to define a bit of flag in Observer option to identifify 
either to add a subject or to delete a subject.

A message of Observe option with positive value causes the notification 
response(s);
and a message of Observe option with negtive value stops nofication, as a 
cacellation.

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----原始邮件----- 
From: weigengyu
Sent: Wednesday, March 05, 2014 2:29 PM
To: Kovatsch Matthias
Subject: Re: [core] Observe Cancellation

Hi Matthias,

My sugggestion is to define a bit of flag in observe option, the bit means
positive/negative request.

If the GET with option of positive request, the server adds an subject to
observe.;
if the GET with option of negtive request, the server will delete the
subject.
So, the negative request functiosn as cancellation.

I think that GET without observer option may have high efficiency,
but it is a little vague in terms of sematics.

regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----原始邮件----- 
From: Kovatsch Matthias
Sent: Tuesday, March 04, 2014 11:21 PM
To: [email-masked]
Cc: [email-masked] ; 'Klaus Hartke ([email-masked])'
Subject: [core] Observe Cancellation

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

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

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 7 Mar 2014 13:25:46 +0530

Can we think about something like GET with both Observe and No-response
options to indicate cancellation? This way we do not need to change the
observe semantics and also will avoid the problem of executing the Observe
code for every GET without Observe. Sorry if I have missed something here.
On Mar 7, 2014 4:28 AM, "weigengyu" <[email-masked]> wrote:

> -----原始邮件----- From: weigengyu
> -----原始邮件----- From: Kovatsch Matthias

---

From: Likepeng <[email-masked]>
Date: Fri, 7 Mar 2014 09:29:43 +0000

>Can we think about something like GET with both Observe and No-response options to indicate cancellation?

This is also weird and has impacts to the existing Observe and No-response handling process.

Kind Regards
Kepeng

发件人: core [mailto:[email-masked]] 代表 Abhijan Bhattacharyya
发送时间: 2014年3月7日 7:56
收件人: weigengyu
抄送: Abhijan Bhattacharyya; [email-masked]
主题: Re: [core] Observe Cancellation

Can we think about something like GET with both Observe and No-response options to indicate cancellation? This way we do not need to change the observe semantics and also will avoid the problem of executing the Observe code for every GET without Observe. Sorry if I have missed something here.
On Mar 7, 2014 4:28 AM, "weigengyu" <[email-masked]<mailto:[email-masked]>> wrote:
HI all,

My suggestion is to define a bit of flag in Observer option to identifify either to add a subject or to delete a subject.

A message of Observe option with positive value causes the notification response(s);
and a message of Observe option with negtive value stops nofication, as a cacellation.

Regards,

Gengyu

Hi Matthias,

regards,

Gengyu

-----原始邮件----- From: Kovatsch Matthias
Sent: Tuesday, March 04, 2014 11:21 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> ; 'Klaus Hartke ([email-masked]<mailto:[email-masked]>)'
Subject: [core] Observe Cancellation

Dear list

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

Hoping for your input
Matthias

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

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 7 Mar 2014 15:16:13 +0530

Well, so far as No-Response is concerned, the draft is still a work in
progress and very much open to new use cases.

On Fri, Mar 7, 2014 at 2:59 PM, Likepeng <[email-masked]> wrote:

> options to indicate cancellation?
>
>
>
> *发件人:* core [mailto:[email-masked]] *代表 *Abhijan Bhattacharyya
> *发送时间:* 2014年3月7日 7:56
> *收件人:* weigengyu
> *抄送:* Abhijan Bhattacharyya; [email-masked]
> *主题:* Re: [core] Observe Cancellation
>
>
>