[core] Dynlink observation attributes

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

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