[core] Review of dynlink

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

Hello dynlink authors,

These are notes from reviewing the dynlink draft; sorry for not
assembling those earlier, I hope they are still appreciated.

The document I'm reading is is post-06 git version dc0bbaff1.

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.

Mandatory and exhaustive bind attribute
=======================================

I think that there are several bind methods missing:

* "Observe+Push". The device executing this binding has neither source
  nor destination resource locally, but will observe (or for a
  "Poll+Push", poll) the source and PUT to the destination.

  This is useful when two devices are to be connected, neither of which
  has a binding site, but a device between them (eg. a border proxy or
  home access point) does.

* "Native". Used for resources on the same server. Neither, or both, of
  observation and pushing are applicable here, but it's really up to the
  server whether it establishes either, short-circuits the resources in
  software or (in case of a gateway I worked on last year) configures
  the bus represented by the resources to link those.

* Possibly "On-Demand" (not fully thought-through). When the destination
  resource is queried, the binding site issues a request to the source
  resource (or uses a fresh cached state maybe) and only responds when
  that arrives, or establishes an observation when the destination is
  observed. (Note that an actuator resource behaves like the hardware
  has an observation on the resource, but that's not the case for all
  resources, and the client might even allow creation of destination
  resources).

In general, I don't think that a bind= attribute should be mandated. A
binding site with the source local and the destination remote will know
to PUT the data, and a site with the source remote will GET+Observe
anyway if it can, and fall back to polling if the observation is
declined.

It's useful to have the methods named and discussed, but I doubt the
need for them to be present in the actual transmitted data (especially
as link attributes, see observation attributes) -- and what would happen
to a `POST /bnd: <coap://example.com/s>;anchor="/a";bind="push"`? Is
that 4.00? That brings us to...

Error behavior of binding tables
================================

How would a binding site react to

* unknown/-implemented schemes?
* permanent or intermittent network unreachability?
* all kind of error codes, especially 4.01/.03?

I don't expect a full treatise of the ways a binding can go wrong in the
document, but at least the issue of creating a traffic storm in response
to an error, whether an error can make a binding just disappear, and
whether the binding site can indicate any error state of a binding
should be covered IMO.

Assorted
========

* boundTo is capitalized differently.

* "The binding conditions are mapped as query string parameters (see
  Section 4)."
  
  Ie. by the time the binding is established, the binding site PUTs the
  parameters the destination resource? Would it need to do that whenever
  the observation is set up, or only once? (That's probably a point that
  could go to to the first section too: there's no text about
  persistence of that state. Is it soft state? How does the client
  know?)

* "A resource using an interface description defined in this
  specification and marked as Observable in its link description SHOULD
  support these observation parameters."

  The only interface description defined in this specification is
  core.bnd, and while it does make sense to observe a binding site for
  monitoring purposes, most of the observation attributes are
  nonsentical on a non-numerical resource. Could this be a leftover from
  when this was a single document with core-interfaces?

* links-json will hopefully pass some time soon. Can those formats be
  used with dynlinks (subject to advertisement in ct= and content format
  negotiation, of course)?

Summary
=======

Many of the issues described with links were not present in the pre-2013
way of passing observation parameters as query parameters to that
observation; I recommend that that way be re-evaluated.

I see much value in having the both bindings and observation thresholds,
and the semantics of the threshold parameters (band etc) seem to be
mature by now, but I would ask for in-depth discussion of the above
points.

Best regards
Christian

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables