Re: [core] Dynlink observation attributes

[Michael Koster <[e-mail]>]

Hi Christian,

I have finally read through these notes again and thought through the questions, and I have some comments as well as some general re-think.

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).

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.

I am also convinced that the idea of storing parameters on PUT and returning them on GET is hard to work out, and I agree we need to rethink that part. I believe we were trying to find a way to make the parameters themselves readable but there are other ways to support this, like in a dynlink.

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.

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 that using a dynlink makes the observe parameters visible and gives the observe relationship an affordance.

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. 

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. 

Many of your text comments can be resolved if we make these simplifications. 

We do not need to include the dysfunctional LWM2M "empty put with query" method at all, or maybe as an appendix and negative example.

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.

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

This also tracks my implementation approach. I have a third method of storing the parameters as static variables for the resource, but that's mostly a refactoring optimization of the binding table where there is only one destination e.g. LPWAN link to a device.

Does this all make sense?

Michael

> On Sep 26, 2018, at 9:35 AM, Christian Amsüss <[e-mail]> wrote:
> 
> Hello Michael,
> 
> as suggested in today's interim meeting, I'd like to get the discussion
> on observation attributes going again.
> 
> To me, the takewaway point of today was that there can be various ways
> of expressing the observation attributes; that we're happy with what the
> attributes can do and their semantics, but that the current way of
> persistently PUT parameters on a link is not ideal for the general use
> case.
> 
> I've left the bulk of my original mail below because I still think it
> gets across the message (though some may be preaching to the choir given
> the above), and stripped unrelated points into a separate thread:
> 
>> Observation attributes
>> ======================
>> 
>> I'd like to refer back to one of my earlierst mails on this mailing
>> list at [CA2013]. The answer to "why not just observe
>> </temp?pmin=10&pmax=60&st=1> as it was in earlier drafts" about caching
>> was not really satisfying, given that this scheme breaks caching just as
>> the original but just worse (previously, a cache would just not have a
>> response ready; now, it sees an observation and thinks the value is
>> current where it's actually from an observation to a client that's not
>> interested in details).
>> 
>> The way of PUTting empty values onto query-parameter identified
>> resources is incompatible with multiple observations.
>> 
>> Moreover, its use is unclear to me from reading it. The sentence "These
>> query parameters MUST be treated as resources that are read using GET
>> and updated using PUT" seems to indicate that they are used like this:
>> 
>> | GET /temp?pmin
>> | 2.05 Content
>> | Payload: "0"
>> 
>> (or however undefined is expressed there)
>> 
>> | PUT /temp?pmin
>> | Payload: "10"
>> | 2.04 Changed
>> 
>> But "Multiple parameters MAY be updated at the same time by including
>> the values in the query string of a PUT" makes it sound like it should
>> be
>> 
>> | PUT /temp?pmin=10&pmax=20
>> | empty payload
>> | 2.04 Changed
>> 
>> -- are both permissible? And if only the latter: How is this accessed
>> with GET? Examples might help, but explicit words would be good too.
>> 
>> Another open question is how to turn those limits off again. Would I
>> just DELETE the <?pmin> resources? 
>> 
>> This was all a whole lot clearer when one could observer
>> 
>> | GET /temp?pmin=10&pmax=20
>> 
>> and have those limits per observation without any new state introduced
>> to the server -- a behavior I would still prefer to see there.
>> 
>> [CA2013]: http://ietf.org/mail-archive/web/core/current/msg04270.html
>> 
>> Observation attributes in bindings
>> ==================================
>> 
>> There are two components in this document I percieve as relatively
>> separate -- the link bindings, and the limiting attributes.
>> 
>> Link bindings work well on their own.
>> 
>> With in-query observation attributes, there would not be any need to
>> define the attributes additionally as link attributes (where, judging
>> from RD discussions, it can be confusing to have both).
>> 
>> Especially troublesome about the attributes is that they are not target
>> attributes, but link attributes. (All other common attributes in
>> link-format documents are target attributes, with the exception of
>> anchor= and rel=/rev= which are core to the web linking model). That
>> means that using other web link formats (eg. CoRAL, RDF; don't know
>> about HSML) will have a hard time expressing those. I think that
>> non-target link attributes should be limited to data that is meaningful
>> on the web linking level and not for arbitrary attributes.
> 
> One closing throught: In implementations, we're often thinking of
> everything that has the same path as the same resource, and query
> parameters just giving details on it. CoAP's REST model does not know
> this distinction -- /temp is something different than /temp?pmin=10, and
> only because we said </temp>;if="core.s" we can conclude that it's
> related to the /temp?pmin=10 resource.
> 
> Let us stick with this, and call /temp?pmin=10 a view on /temp, like
> through a lens that blurs an image.
> 
> Best regards
> Christian
> 
> -- 
> This may seem a bit weird, but that's okay, because it is weird.
>  -- perldata(1) about perl variables
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core