Re: [core] PubSub - Questions round 1

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

Hello working group,

On Wed, Sep 13, 2017 at 09:10:34PM -0700, Jim Schaad wrote:
> This would be rule c
> of section 2.1 of RFC6690.  This rule seems to have been modified for the
> /.well-known/core to say only use the scheme + authority and ignore the path
> to the resource.  However, I do not believe that this rule is suspended in
> this case.  This means that the return value for figure 4 would be
> "</currentTemp>;rt=temperature;ct=50".   Do you believe that I am wrong?

There's nothing special about .well-known/core, but Jim did discover
something nasty that I did not spot before:

RFC6690 link-format not only resolves the target relative to the link's
Context, but also has the default Context depend on the target
reference and strips any implicit base URI using the Origin concept of
RFC6454; something known neither from RFC5988 nor the current RFC8288.

This breaks the examples and convenient representations of
core-interfaces, core-coap-pubsub, and contradicts the mental model of
link-format semantics of everyone I have ever talked to about it. Unless
you have an anchor, links need to be absolute or path-absolute to behave
as expected. (resource-directory is largely safe because it exports
absolute URIs in resource lookups due to an already known part of those
issues).


So when you see

  GET coap://host/123/456/ returning
  <789/abc>;rel=member,<777/569>;rel=description

  it expresses links

  coap://hosts/ --(has member)--> coap://host/789/abc
                --(has member)--> coap://host/777/569

  where you would have expected (also in accordance to RFC8288)

  coap://hosts/123/456/ --(has member)--> coap://hosts/123/456/789/abc
                        --(has member)--> coap://hosts/123/456/789/569
  .

On the other hand,

  GET coap://host/123/999/ returning
  <789>;rel=boundto;anchor="coap://other/567/"

  expresses per RFC6690

  coap://other/567/ --(bound to)--> coap://other/567/789

  where a more intuitive interpretation would be

  coap://other/567/ --(bound to)--> coap://host/123/999/789

  .

Also, the rules make it impossible to express the respective RFC8288
links at all in a relative fashion; to make these statements, the server
producing the representation needs to be aware of the host name it is
queried as (and to draw the right conclusions, needs to agree with the
client on this). This is prone to misunderstandings when reverse proxies
are in use, and means that links that can be statically known (and thus
served directly from flash) need to be needlessly assembled by
constrained devices.


There is no motivation for this deviation from web linking in the
document.

It is my impression (and please PLEASE reply if I'm wrong) that nobody
has implemented those rules as they are laid out, at least not in a
system that deals with links where it makes a difference.

6690 is a request for comments. My I comment that its href/anchor
component is broken, and I propse that we do an RFC6690bis that
redefines ct=40 into to be closer to RFC8288.

If my impression about the state of deployment is wrong, my next best
suggestion is to deprecate it in favor of something that has better
defined semantics like CBOR-link-format (it does ... right?).


Best regards
Christian

-- 
Ceterum censeo Carthaginem delendam esse.
  -- M. Porcius Cato