[core] (rest of) Re: Review of dynlink

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

To better keep track of the discussion, here's the portions of my
original review that are not taken to the new thread at [1]; unquoted
for readability:

----

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.

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


[1]: https://mailarchive.ietf.org/arch/msg/core/jA_zWgxgd01fvwiTIgAyZTTb5HY

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