Re: [core] [T2TRG] OCF Observe on special interfaces, design question, RFC requirements?

[Klaus Hartke <[e-mail]>]

Michael Koster wrote:
> Does this violate any of the current requirements in RFC7252 or RFC7641, or other specifications?

I think RFC 7641 is pretty clear that a 2.05 (Content) notification
contains a resource state representation and not a representation of
changes since the last notification.

RFC 7641: "The goal of the protocol is to keep the resource state
observed by the client as closely in sync with the actual state at the
server as possible."

"Notifications are additional responses sent by the server in reply to
the single extended GET request that created the registration. [...]
The only difference between a notification and a normal   response is
the presence of the Observe Option."

RFC 7252: "The payload returned with the [2.05 (Content)] response is
a representation of the target resource."

RFC 7641: "As notifications are just additional responses sent by the
server in reply to a GET request, they are subject to caching as
defined in Section 5.6 of RFC 7252 [RFC7252]."

A good way to think of the Observe mechanism is to see it an
optimization of polling: Every time a client gets the response in
reply to a GET request without Observe option, it gets the current
representation if the resource. That representation only depends on
the resource state, never on the response to a previous request. Every
time a client gets a notification in reply to a GET request with
Observe option, it gets the current representation if the resource.
That representation only depends on the resource state, never on a
previous notification.

When observing a resource with a rather large representation, it might
often make more sense to observe a projection of that resource. That
is, to observe a resource X whose state depends on the state of
another resource Y.

Examples of possible resource state projections if the state of Y is a number:

* The state of X is that number rounded to a multiple of 5.
* The state of X is that number clipped to the range 0--100.
* The state of X is the moving average of that number over the last 60 seconds.
* The state of X is that number sampled every other second.
* The state of X is the difference between that number and 9000.

Examples of possible resource state projections if the state of Y is a
list of items:

* The state of X is the number of changes to that list since its creation.
* The state of X is the timestamp of the last change to that list.
* The state of X is a list of the last 10 additions/removals to that list.
* The state of X is a list of the additions/removals to that list
since 2019-07-10T00:21:00+0200.

Anything where the notifications depend on previous notifications
(e.g., time elapsed since the last notification, value has changed by
more than some value since the last notification, additions/removals
to some list since the last notification, etc.) is not a projection of
resource state and thus not pollable nor observable.

Klaus