Subject: [core] RFC6690: target and link attributes (and dynlink applications)

From: Christian Amsüss <[email-masked]>
Date: Fri, 6 Oct 2017 15:31:09 +0200

Hello CoRE WG,

reviewing the current dynlink draft for an application, its use of link
attributes struck me as odd as (from reading RFC5988) I interpreted link
attributes to be always attributes of the target and not properties of
the link, so

<coap://....com/s/light>;rel="boundto";anchor="/a/observing";bind="obs",
<coap://....com/s/light>;rel="boundto";anchor="/a/polling";bind="poll"

is semantically equivalent to

<coap://....com/s/light>;rel="boundto";anchor="/a/observing";bind="obs";bind="poll",
<coap://....com/s/light>;rel="boundto";anchor="/a/polling"

because target attributes are not tied to the link but only to the
target.

In RFC6690, I found the explicit mention that an attribute "[describes]
the link or its target", so unless an attribute is known to be a target
attribute (which, by 5988, all seem to be), it can not be freely moved
between links.

Is this a deliberate deviation from 5988? Can dynlink (and
resource-directory, whose implementations can be tempted to do the above
transformation) rely on this staying around?

If this is something we actively want to have, IMO we should ask to have
it included in 5988bis; otherwise I think we should not rely on it. I'm
a bit worried that having a feature like this creates divergence between
two seemingly compatible formats and impedes code sharing between a
link-header and link-format implementations.

Please let me know what you think of the situation
Christian

-- 
Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)