Subject: [core] explicit observe de-registration

From: Thomas Fossati <[email-masked]>
Date: Mon, 13 Feb 2012 11:35:24 +0100

Wouldn't it be cleaner to have an explicit Observe de-registration request from the observer to the subject ?

It'd work with both CON and NON observations (instead of being CON-only [*]) and would be more efficient with sleepy observers, avoiding all the useless retransmission implied by an unreachable node that has entered the sleep state.

Thomas.

[*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent in reply to a NON message, but then 4.4.4 associates RST to CON only (consistently with the usage in current Observe I-D.).  To add some more entropy, the changelog says that 05->06 transition included an "Allowed RST message in reply to a NON message with unexpected token", but I can't see it anywhere in -08.  
This all leaves some degree of ambiguity about whether RST is a valid response to a NON message or not.

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 13 Feb 2012 20:22:52 +0100

> Wouldn't it be cleaner to have an explicit Observe de-registration request from the observer to the subject ?

A client can send a GET request without Observe Option to get it
removed from the list of observers; see section 4.1. Maybe some
matching text should be added to section 3?

Klaus

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 13 Feb 2012 21:26:23 +0100

On Feb 13, 2012, at 8:22 PM, Klaus Hartke wrote:
> removed from the list of observers; see section 4.1.

Great, you're right.

> Maybe some matching text should be added to section 3?

Thanks, that would help.

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 13 Feb 2012 21:39:13 +0100

>> Maybe some matching text should be added to section 3?

Something like this?

3.5.  Cancellation

   When a client rejects a notification (confirmable or non-confirmable)
   with a RST message or when it performs a GET request without an
   Observe Option for a resource, the server will remove the client from
   the list of observers.  The client MAY use either action at any time
   to indicate that it's no longer interested in receiving notifications
   about the resource.

Klaus

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 13 Feb 2012 22:22:48 +0100

>   to indicate that it's no longer interested in receiving notifications

I like the explicit subsection.

One tiny adjustment:
"[...] performs a GET request without an Observe Option to a currently observed resource, the server will remove the client from the list of observers for that resource. [...]"

Admittedly an awful abuse of the "observ-" stem, but one that should leave no residual ambiguity -- hopefully :-)

Thank you very much.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 15 Feb 2012 10:26:58 +0200

On 2/13/12 10:39 PM, Klaus Hartke wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
Hi there,

I like the proposal, however I think that we should really clarify if 
RTS works also
non-confirmable msg or not.

The MUST in Section 4.4.4 of core-coap draft seems not to allow it:

    4.4.4.  Reset (RST)

        A Reset message indicates that a specific confirmable message was
        received, but some context is missing to properly process it.  This
        condition is usually caused when the receiving node has rebooted and
        has forgotten some state that would be required to interpret the
        message.

        A reset message MUST echo the Message ID of the confirmable message,
        and MUST be empty.

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 15 Feb 2012 10:34:45 +0200

Hi there,

from on the Thomas mail (see below) and the thread discussion related on 
how to cancel an observation
it seems that the core-coap 08 draft needs some text to clarify how the 
RST message works and when it is possible to use it.

sections seems to imply that RST MUST be used only with confirmable messages

    4.4.4.  Reset (RST)

however, section 4.2 states that it MAY be used also with an Unreliable 
Message

    4.2.  Unreliable Messages

        As a more lightweight alternative, a message can be transmitted less
        reliably by marking the message as "non-confirmable".  A non-
        confirmable message MUST NOT be acknowledged by the recipient.  If a
        recipient lacks context to process the message properly, it MAY
        reject the message with a reset message or otherwise MUST silently
        ignore it.

-- 
Salvatore Loreto
www.sloreto.com