Re: [core] Dynlink observation attributes

[Christian Amsüss <[e-mail]>]

Hello Michael,

On Tue, Nov 06, 2018 at 12:05:57AM -0800, Michael Koster wrote:
> I am convinced that we need to support observe attributes as query
> parameters to an observe request, and include them in the request
> caching. This makes sense as an application pattern and as a
> sub-pattern for dynlinks (below).

Glad you agree.

> The modified URI may be thought of as a newly defined resource that
> exposes a coarser grained dynamic representation of the same variable
> indicated by the other URI parameters. I haven't fully thought through
> the caching issue with etags and lifetimes, but it seems like there
> will be ony one set of parameters feeding any given cached resource.
> The notifications should be cacheable.

Maybe even a bit better: I think that a proxy that has learned (eg. by
having seen interface type information earlier) that a resource supports
query attributes[1] could, when receiving a second observation on the
same "resource" with different filters, pick a more generic one and
serve the more specific ones after applying its own filtering.

[1]: I think it'd make sense to define an interface type for that, for
otherwise no client can be sure that /t?pmin=5 is actually a view on /t
and not something completely different.

> On that, I believe that the use of target attributes in a dynlink is
> quite reasonable if we consider that the target of the link is always
> the source of the transfer when rel=boundto, and that we always use
> the observe mechanism as an architectural model => they are always
> observe attributes, and they apply to the target of the link which is
> hte source of the transfer.

It also makes it very hard to move those links over to the semantic web
world for reasoning, as those target attributes are per-link and not
per-target.

If there's a statement like

<coap://sensor/temp?st=2>;rel=boundto;anchor="/monitor"

then that can be processed on easily in RDF or any other information
model that does not carry information per-link in the way we had
sketched for JSON-LD enrichted links-json during IETF96 in Berlin.

If the statement is

<coap://sensor/temp>;rel=boundto;st=2;anchor="/monitor"

then all semantic-web style processing needs to be aware of all those
attributes, and can't wrap the information in a set of statements that
includes `/monitor is boundto coap://sensor/temp` as the step
information can't hook onto that statement.

(Also, having the parameters in the target makes the binding site easier
to implement, as it won't have to do URI fiddling but just takes a URI
and observes it).

> The "native" case is simply an optimization and not an architecture
> permutation. A practical implementation may re-use the observe
> mechanism for local transers. 
>
> Note also that the "bind" attribute is not strictly needed if we apply
> these other constraints, as you point out. We may always assume
> observe as an architectural model. This can be generalized to allow
> the link to be stored anywhere that a client function can be
> implemented, especially useful if we don't want to modify existing
> servers. 

I'm not saying it is very special, I'm more saying that GET/observe and
PUT are not.

> Not sure if we need polling but if we do, it's probably not the same
> relation as "boundto". The transfer would likely be from source to
> target like rel=polls, as in "target polls context". Only one
> attribute of poll interval could be supported, and of course the
> others could be modeled on observers of the target resource after the
> polling, using the algorithm. 

The binding site may not have control over whether what actually happens
is polling or observation (and thus the distinction is of limited use);
per RFC7641 Section 5, intermediaries could make the same observation
polling-based over one hop and actually observing on the next one.

> In the draft we can describe the observe attribute first, then
> describe the use in dynlinks, then describe a link table example
> implementation. I think a lot of the confusion can be alleviated this
> way, and we can focus on preferred patterns.

That's certainly a structure that will help, even now that both
components stay in the same document.

> Note that using a dynlink makes the observe parameters visible and
> gives the observe relationship an affordance.
> 
> Does this all make sense?

The affordance part does not, possibly because I've heard the term only
in the context of high-level usefullness. As I understand the term, he
affordance would be informing a heating valve of a room temperature, and
that affordance can be implemented in the CoRE ecosystem by placing a
dynlink.

> Does this make sense? I could write up a rough strawman draft with the
> changes.

I'd be happy to read that.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom