Re: [core] Report on first Resource Directory plugtest

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

Hello Carsten, hello Jim,

On Fri, Apr 13, 2018 at 03:01:05PM +0200, Carsten Bormann wrote:
> >> Well, the general feeling was that instead of going for a 6690bis, we
> >> maybe want to let the link-format just fade out (In favor of
> >> links-json/-cbor).
> > 
> > link-json/-cbor is not helping with the issue of [1].
> 
> No; the intention would be to develop links-json/-cbor in such a way that itself doesn’t have the issue.
> (I.e., decouple it a bit from the idiosyncrasies of RFC 6690.)

That means that a simple encoder like Appendix A becomes quite a bit
more complex (it needs to learn URI parsing), as do implementations like
Jim's. ("Doing this is going to make my life as an implementor really a
mess. [...] I think this would make more problems that it would solve.")

I'm not saying it should not be done, just pointing out that it's a big
step for a document at that stage.

To address the rest of Jim's text on that topic:

> What would this mean for serializing out /.well-known/core - are the
> meanings different if one serializes to cbor as opposed to
> link-format?  

I can't tell for links-json+cbor, but in general yes.

For example, what is serialized in link-format as

<coap://1.2.3.4/foo>;if="core.s";rel="x";anchor="coap://1.2.3.4/bar",
<coap://1.2.3.4/baz>;rel="baz";if="core.a";rel="x";anchor="coap://1.2.3.4/bar",

could be serialized equivalently in CoRAL(ish) as

[
  [2, // link
    ignore, // relation
    [ // target
      [1, 'coap'], // Scheme
      [3, h'01020304'], // IP literal,
      [6, "bar"], // path "bar"
    ],
    [
      [2, // link
        rel:hosts,
        [[5, 0], [6, "foo"]], // absolute path with one component "foo"
        [
          [2, attr:if, "core.s"],
        ],
      ],
      [2,
        rel:baz,
        [[5, 3]], // relative path "baz" constructed from name of the rel
        [[2, attr:if, "core.a"]],
]]]]

which is not at all alike the link-format serialization in that it even
constructs relative references in a completely different way.


As long as an RD only supports link-format and possibly strictly
link-format-compatible CBOR/JSON versions are around, the data model can
be an ordered string-valued multi-dictionary with special meaning but
only string handling for href and anchor. With other serializations,
those need to become URIs. The stable data model is annotated web links
between URIs; I hope that RDF is a suitable data model too (HSML and
CoRAL seem to indicate that). The href-and-anchor-as-strings model is a
simplification that can be suitable for link-format, but not the general
case.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom