Cancel Observation-Composite operation format

[cjacquinot]

• RFC 7641
• section 3.6

In some circumstances, it may be desirable to cancel an observation and release the resources allocated by the server to it more eagerly. In this case, a client MAY explicitly deregister by issuing a GET request that has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister). All other options MUST be identical to those in the registration request except for the set of ETag Options. When the server receives such a request, it will remove any matching entry from the list of observers and process the GET request as usual.

• OMA-TS-LightweightM2M_Transport-V1_1_1-20190617-A
• Section 6.4.5
• Table: 6.4.5.-1 Operation to Method and URI Mapping (Information Reporting Interface)

In Observing Resources in the Constrained Application Protocol Specification (RFC 7641) it says that to cancel an observation, the CoAP packet sent should have the same token and same options than for the Observe operation.

In LwM2M Specification, the behaviour is according to the one explained in Observing Resources in the Constrained Application Protocol Specification (RFC 7641):

• The Cancel Observation operation got the same options (URI path) than its corresponding Observation except for the Observe option which is set to 1
• The Cancel Observation-Composite operation got the same options than its corresponding Observation except for the Observe option which is set to 1 with the URIs path in its payload

For Cancel Observation-Composite operation the payload add non negligible bytes in the packet. Since the payload is not an option in the CoAP packet and the token packet should be enough, why should we include a payload in Cancel Observation-Composite operation ?

[hannestschofenig]

Good observation. I let Mojan provide his perspective, as one of the persons who came up with this text.

[hannestschofenig]

Actually, we are using the same logic in the ordinary Cancel Observation as well. Hence, it is consistent with the previous functionality.

[cjacquinot]

I understand the format for the Cancel Observation operation because the URI of the observation in the CoAP packet is an option.

But the URI in the CoAP packet for Cancel Observation-composite is in the payload and not an option.

Does this mean that if we received a Cancel Observation packet with the exact same token and options than the Observe-Composite, the Observe-Composite should be cancel (1) or not (2)?

(1). From CoAP Specification (RFC 7641 and RFC 8132) (2). From LwM2M Specification (OMA-TS-LightweightM2M_Transport-V1_1_1-20190617-A)

[mojanm]

As indicated in the earlier comments, URI path is present in Get method while in FETCH the URI Paths for target resources are in the payload. So in scenarios when there are multiple Observe-Composites active between the same client and server, the question is how can LwM2M layer at the server unambiguously cancel one of them. Depending on implementation, this obviously can be achieved. But the specification should be implementation agnostic? Without going into detailss I believe any implementation that can unambiguously identify witch Observe-Composite to cancel without any reference to URI path could also use CoAP Reset to achieve the same result. Therefore, it will be best to leave the specification as it is.

[sbernard31]

So in scenarios when there are multiple Observe-Composites active between the same client and server, the question is how can LwM2M layer at the server unambiguously cancel one of them.

With my current understanding of RFC 7641, I guess this is not allowed to have several observe relation on same resource. (see #528)

---

About this particular topic, I'm not sure to get the rational about sending the payload on Cancel Observation ? this sounds not required by CoAP RFC.

From a CoAP perspective, even if you consider you could established several observe relation on / (which I think it's not really allowed), you should be able to match the observe relation by using the Token. :thinking:

But the specification should be implementation agnostic?

I'm not sure to get what means this, "implementation" means different kind of CoAP libraries ? or means different transport layer (e.g. CoAP, MQTT, ...) ?

For libraries, I think they just need to respect RFC 7641 and so no need to use payload. For transport layer, I guess maybe some layer could need the URI list but CoAP don't need it so in the Table: 6.4.5.-1 Operation to Method and URI Mapping (Information Reporting Interface) which is dedicated to CoAP we could avoid to send URIs in in the payload. :thinking:

[sbernard31]

About my previous comment, I get some answers from IETF CoRE mailing list, and it seems my understanding was wrong for both point because payload of FETCH request is part of the cache key. :grimacing:

Following this conversation, from CoAP RFC point of view, it seems that :

• nothing prevent to have several observe relation established on "/" if payload of FETCH is different.
• Active cancel request with FETCH should repeat the payload.

See : https://mailarchive.ietf.org/arch/browse/core/?gbt=1&index=ZPgke9Hc5jdIdgWrR8KxKTxnB-4

[hannestschofenig]

This issue was clarified in version 1.2 of the LwM2M specification. It was not backported to earlier versions.