Subject: [core] CoAP over TCP and observing values

From: Martin Scheffler <[email-masked]>
Date: Tue, 4 Apr 2017 13:24:33 +0200

Hi CORE,

while researching the different capabilities of CoAP I think I stumbled
onto an issue:
the CoAP over TCP transmission does not have ACK or RESET messages because
TCP is already reliable.
But the observation mechanism from RFC 7641 uses RESET messages to
unsubscribe from observed values. AFAIK there is no other way to
unsubscribe from observations, so unsubscribing is not possible when using
TCP.
Is this true or is there something I don't get? Is this a problem of the
TCP RFC or of the observation RFC?

Cheers,
Martin

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Apr 2017 13:46:40 +0200

> On 4. Apr 2017, at 13:24, Martin Scheffler <[email-masked]> wrote:
> 
> Hi CORE,
> 
> while researching the different capabilities of CoAP I think I stumbled onto an issue:
> the CoAP over TCP transmission does not have ACK or RESET messages because TCP is already reliable. 
> But the observation mechanism from RFC 7641 uses RESET messages to unsubscribe from observed values. AFAIK there is no other way to unsubscribe from observations, so unsubscribing is not possible when using TCP. 

Actually, there is; see deregister in Section 2.

Reset messages are used in UDP CoAP as a reply to messages that do not make sense for the recipient.  The case addressed for observe is that a client crashes and loses all knowledge about an observation request it placed; when it receives the next notification, it can answer with a Reset message to indicate that it is lacking the context to process it.

With TCP CoAP, a crashing and restarting client would reset the TCP connection upon receiving any further TCP packet on that connection it no longer knows about.  That causes the TCP connection to go away, and with it all the observation interests established over that connection.

(The assumption is here that there is fate sharing between the TCP connection state and the application layer observation interest state.  If the latter can be forgotten without forgetting the former, there would be a need for a further mechanism.)

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Tue, 4 Apr 2017 04:54:10 -0700

Hi Martin,

There is an application layer mechanism defined to cancel observe, by the client sending a value of observe=1 in the coap option header.

When included in a GET request, the Observe Option extends the GET
   method so it does not only retrieve a current representation of the
   target resource, but also requests the server to add or remove an
   entry in the list of observers of the resource depending on the
   option value.  The list entry consists of the client endpoint and the
   token specified by the client in the request.  Possible values are:

      0 (register) adds the entry to the list, if not present;

      1 (deregister) removes the entry from the list, if present.

This is the preferred method for a client to indicate it no longer wishes to receive notifications.

Best regards,

Michael

> On Apr 4, 2017, at 4:24 AM, Martin Scheffler <[email-masked]> wrote:
> 
> Hi CORE,
> 
> Is this true or is there something I don't get? Is this a problem of the TCP RFC or of the observation RFC?
> 
> Cheers,
> Martin
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core