search

core-wg / corrclar

Corrections and Clarifications to CoRE standards
Other
0 stars 0 forks source link

Observation: Revisit MUST on Observe in successful notifications #20

Open chrysn opened 2 years ago

chrysn commented 2 years ago

Current RFC7641 says that "A 2.xx notification MUST include an Observe Option with a sequence number".

If it ever gets an overhaul, I'd consider dropping this in favor of the more general statement that any non-Observe response is ordered after any numbered observe response. That is compatible with the current semantics on unsuccessful responses, but allows for volatile-but-stabilizing resources to send notifications like "Observe: N, Max-Age: 20" several times, until eventually sending "Max-Age: 65535" indicating that this resource has converged. (Think observing the location indicated by a POST request for a long-running process).

In terms of compatibility with existing implementations, I think it'll be fine: A strict client would treat it as an error, just as it'd treat the 5.03 that is currently the best the server can do to say that it doesn't want to keep this observation around any more.

cabo commented 2 years ago

Nice!

Where should this go into the document? Should we have a section "Opportunities for small fixes and improvements" or some such?

chrysn commented 2 years ago

I think the structure of RFC section and component subsection (here: "RFC 7641" / "4.2: Notifications") fits here as well.

Text could be:

RFC 7641 requires that every successful notification "MUST" have an observe option.

For response reordering (which generally relies on the sequence number), the response without an Observe option is ordered after all notifications that have an Observe option. This is consistent with the handling of error responses, which already do not carry an Observe option and are also final. It is RECOMMENDED that this notification is sent as a confirmable message on transports that make such a distinction.

This is primarily useful for for resources that are volatile for some time and then converge to a final state (e.g., the state of long-running processes triggered by a POST request). When the resource reaches that state, there is no use in keeping an observation around, but also no reason to send a notification of an error state. For these notifications it is useful to send a long Max-Age. Clients generally may fall back to polling when observation fails; the long Max-Age ensures that they take their time before polling again.