Subject: Re: [core] Resource Directory plugtest

From: Christian Amsüss <[email-masked]>
Date: Tue, 3 Apr 2018 10:21:22 +0200

Hello parties interested in the RD interop,

we will have the plug test on April 10th, starting 14:00 UTC; a voice
and text chat room is available at IETF Jitsi[1] to coordinate, exchange
addresses and test results.

I've expressed the participant survey as an online questionnaire at [2];
participants that have not yet answered my plain text version please
fill this out before the 7th.

Best regards
Christian

[1]: https://jitsi.tools.ietf.org/rd-plugtest
[2]: https://chrysn.limequery.org/999235

-- 
You don't use science to show that you're right, you use science to
become right.
  -- Randall Munroe

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 12 Apr 2018 23:12:00 +0200

Hello,

we have had a successful plug test in two sessions on Tuesday with a
total of 4 implementors[1], 3 resource directories and 7 endpoints
(counting full and simple endpoints independently), thereof 2 (one full
endpoint, one simple endpoint) on embedded (class C2) systems.

Most endpoints could register right away once configured properly, and
be looked up by other parties.

Issues we encountered were:

* Problems from lower layers[2]

* Various implementation bugs (programming errors, non-intuitive
  configuration)

  Most of these could be fixed ad-hoc by the participants.

* Incomplete implementations of RD functionality

  * Lookup: One server has not yet implemented support for
    arbitrary registration attributes at the lookup side, and only
    supports querying for known parameters without wildcards; this was a
    known limitation of this work-in-progress implementation.

  * Lookup: The requirements of -13 to have absolute references in both
    the href and anchor of resource lookup has only been implemented on
    one server. This was probably due to authors having carried over the
    behavior from earlier draft versions.

  * Discovery: The embedded endpoint implementation did not implement
    the discovery step but needed to be configured with a full
    registration URI.

* Only little unclear parts in the current RD draft

  * May a con= argument be present in a simple registration? (Probably
    not, though this precludes simple registration over TCP).

  * Can there be a Location-Query option in a registration response?
    (Probably not, we just didn't say that.)

  * Can a con= have query parameters? (Certainly not intended, it just
    didn't even occur to anyone before.)

  Those parts are being fed into the process of refinding the
  resource-directory document, in parallel to the other input we've been
  receiving.

All tested endpoints could register on the servers they were tested
against[3]. Endpoints for full registration did registration, updates
and removal of registrations (where supported; some endpoints (esp. the
embedded one) chose not to implement updates or removal). We found the
resources advertised by the endpoints in the resource looup interfaces
using the supported media types (application/link-format for all
involved, +cbor and +json where supported).

One of the registering endpoints has not seen any updates since at least
-11; that did not impede its ability to register.

All things considered, we regard these first tests as successful.

Topics we would like to explore in a future second round of this plug
test:

* see whether all participants can implent their missing features (esp.,
  see how well full URI discovery works from embedded systems)

* extensions to the RD (RD-DNS-SD, distributed RDs)

* groups (those are only supported by one implementation so far)

* actually accessing the advertised resources

Best regards
Christian

-- 
Ceterum censeo RFC6690 esse revidendam.

[1]: Test participants were Jim Schaad, Ivaylo Petrov (with ackl.io's
  resource directory), Hauke Petersen (with endpoints implemented on
  RIOT) and Christian Amsüss (with aiocoap)

[2]: In detail, those were:

  * Production and parsing of invalid RFC6690 (which link attributes
    need to be quoted, trailing commas, parsers expecting a '=' after
    'obs')
  * Errors on CoAP level (NON vs. ACK, Accept ignored)
  * URIs needing explicit port values
  * Incompatible TLS implementations (two participants have basic
    support for CoAP over TLS, but with disjoint authentication options)
  * Routing / name resolution problems

  Those problems were understood (with the help of the respective
  specifications, where needed), and are worked on by the authors.

  I've seen a similar class of issues during the OSCORE plug tests. We
  might consider collaborating on building a test suite for some of
  those so that future implementors can self-test their ground work
  during development.

[3]: Not all were tested against all due to a timezone mismatch that
  caused the test to be split in two sessions.

---

From: peter van der Stok <[email-masked]>
Date: Fri, 13 Apr 2018 09:04:33 +0200

Hi Christian,

thanks for this very useful work
Some questions/ remarks below.

>     not, though this precludes simple registration over TCP).
certainly not; it beats the purpose.
We may add text in RD to address the TCP part.
>     (Probably not, we just didn't say that.)
to what purpose?
>     didn't even occur to anyone before.)
It states explicitly that it is a scheme//authority string, no query 
parameters possible;
The simplicity helps to specify an already complex subject
> 
>   Those parts are being fed into the process of refining the

to be filled into the github, I hope.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Apr 2018 09:14:27 +0200

Hi Christian,

this is great input.  Let me pick out two items here:

>    (Probably not, we just didn’t say that.)

Why not?
(Sorry, I missed out on responding to Jim’s earlier message on this.
I’m trying to find out why we need to restrict the server’s flexibility in choosing the URI here.
Maybe there is a good reason, I’d just like it to be more explicitly stated.)

> Ceterum censeo RFC6690 esse revidendam.

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).

>    need to be quoted, 

Right.  I think we really should be following RFC 8288 here and asking implementations to be robust to the misguided “this attribute needs to be quoted” decisions we made in RFC 6690.

Maybe we can put a few updates to 6690 in links-json?

Grüße, Carsten

---

From: Christian M. Amsüss <[email-masked]>
Date: Fri, 13 Apr 2018 13:03:02 +0200

Hello Peter, Carsten,
hello Jim (responding cross-thread to the Location-Query point),

(removing DNS-SD from the thread because I do not expect those topics to
be particularly interesting there)

> to be filled into the github, I hope.

yes, as I am finally going thorough the existing issues and changes.

> Maybe there is a good reason, I’d just like it to be more explicitly stated.)

The good reason is that we are using URI templates in the registration
update operation: {+location}{?lt,con,extra-attrs*}

While it should be intuitively obvious that for location="x://y/z?a=b"
and lt="42", the produced URI is "x://y/z?a=b&lt=42", RFC6570 Section
3.2.8 does not describe peeking back at what has been expanded to the
left side, but prescribes a "?" to be used before the first value, so
the produced URI would be "x://y/z?a=b?lt=42" (or possibly ?a=b%3Flt=42
but not ?a=b&lt=42).

If I'm reading RFC6570 wrong here, Location-Path can be allowed and I'd
be happy.

Otherwise, we have to choose between using formal URI templates here
(vs. saying that some query parameters can be appended) and allowing
Location-Query. (Requiring anyone to understand ?foo=bar?baz=qux as two
keyswould be madness so it's not an option.)

> 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].

Whoever receives a link-format+json document and wants to follow a link
given there needs to take the href and the anchor, and look up in
RFC6690 Section 2.1, which is the very root of my misgivings about the
situation.

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

> Right.  I think we really should be following RFC 8288 here and asking
> implementations to be robust to the misguided “this attribute needs to
> be quoted” decisions we made in RFC 6690.
> 

I don't know from a procedural PoV -- can we? And how far can that go?

Best regards
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Apr 2018 15:01:05 +0200

On Apr 13, 2018, at 13:03, Christian M. Amsüss <[email-masked]> wrote:
> keyswould be madness so it’s not an option.)

I must admit that I read

   o  append "?" to the result string if this is the first defined value
      or append “&” thereafter;

as doing the right thing, but then maybe I don’t understand “the first defined value” (of what?).

We could also use formal URI templates and just say that they are to be interpreted in the sensible way described above.

(I’m not a fan of RFC 6570 URI templates at all, because the approach is full of brokenness of the kind you describe(*); but it was available at the time…)

> 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.)

> RFC6690 Section 2.1, which is the very root of my misgivings about the

Not if we don’t define it that way.

Generally, the idea is that an RD consumer is not affected by this (we always use absolute URIs), and an RD submitter  would be affected only if it uses legacy link-format.

> I don't know from a procedural PoV -- can we? And how far can that go?

In updating a document, we can go as far as we want.
But of course we want to be reasonable and make sure we don’t invalidate existing implementations of link-format.
Instead of doing a link-format v2, the idea is live with v1 and move over to JSON/CBOR.

Grüße, Carsten

(*) the usual mistake of trying to describe operations on the data model level in terms of operations on the serialization level.  That got fixed in RFC 8288, but not in RFC 6570 templates.  In the end, I believe we’ll be much better off with a CORAL-like representations of URIs…

---

From: Jim Schaad <[email-masked]>
Date: Sun, 15 Apr 2018 11:47:32 -0700

> -----Original Message-----
> From: Carsten Bormann <[email-masked]>
> Sent: Friday, April 13, 2018 6:01 AM
> To: "Christian M. Amsüss" <[email-masked]>
> Cc: peter van der Stok <[email-masked]>; Jim Schaad
> <[email-masked]>; Core WG mailing list <[email-masked]>
> Subject: Re: [core] Report on first Resource Directory plugtest
> 
> > (removing DNS-SD from the thread because I do not expect those topics
> > to be particularly interesting there)
> >
> > the produced URI would be "x://y/z?a=b?lt=42" (or possibly
> > ?a=b%3Flt=42 but not ?a=b&lt=42).
> >
> > If I'm reading RFC6570 wrong here, Location-Path can be allowed and
> > I'd be happy.
> >
> > Location-Query. (Requiring anyone to understand ?foo=bar?baz=qux as
> > two keyswould be madness so it’s not an option.)
> 
> I must admit that I read
> 
> 
> We could also use formal URI templates and just say that they are to be
> interpreted in the sensible way described above.
> 
> (I’m not a fan of RFC 6570 URI templates at all, because the approach is full of
> brokenness of the kind you describe(*); but it was available at the time…)

I would agree that I would not have read this as needing to have two "?" characters in the query parameters.  My issue is that I worry about the case that an RD decides to use foo=XXX as the location query and then some application decides to use foo as a query parameter in the extra parameters or in a link description.  This works fine on RD implementation #1 because it is just using a location path to point to the end point, but when it hits RD implementation #2 which is using the location query as well it starts failing.  

It is also slightly a pain because it is harder to combine query parameters than it is to just use a path, but that can easily be dealt with.

Jim

> > Whoever receives a link-format+json document and wants to follow a
> > link given there needs to take the href and the anchor, and look up in
> Generally, the idea is that an RD consumer is not affected by this (we always
> use absolute URIs), and an RD submitter  would be affected only if it uses
> legacy link-format.
> 
> > [1]:
> >
> https://mailarchive.ietf.org/arch/msg/core/LS0ccxtH8nEVuy73iZoRkkfBpmw
> >
> >> Right.  I think we really should be following RFC 8288 here and
> >> asking implementations to be robust to the misguided “this attribute
> >> needs to be quoted” decisions we made in RFC 6690.
> >>
> (*) the usual mistake of trying to describe operations on the data model level
> in terms of operations on the serialization level.  That got fixed in RFC 8288,
> but not in RFC 6570 templates.  In the end, I believe we’ll be much better off
> with a CORAL-like representations of URIs…

---

From: Jim Schaad <[email-masked]>
Date: Sun, 15 Apr 2018 11:53:25 -0700

> Instead of doing a link-format v2, the idea is live with v1 and move over to

Doing this is going to make my life as an implementor really a mess.  I will no longer be able to simply have a single representation of the internal data structure and do the parsing as serialization to a common format.  I am now going to need to remember what the original representation was and do the serializations differently based on that value.   In addition to this, all of my internal calls to setup the link format to begin with need to have this distinction so that things get serialized correctly.   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 think this would make more problems that it would solve.

Jim

---

From: peter van der Stok <[email-masked]>
Date: Mon, 16 Apr 2018 10:26:16 +0200

Hi all,

The extra-attrs* in the template has more consequence than I originally 
thought.
Apparently, it allows any query-parameter used in a given link to be 
used in the RD and given a value.
The consequence is that we do not have a resource directory but 
something more fine-grained: a query directory.
A user can specify a large number of queries with different values in a 
link specification.
The RD can then be queried for links with for example: 
nm="petervanderstok".

Don't we want to contain the possible query parameters that we allow in 
extra-attrs*.

An alternative is that exra-attrs* provides a list of the query 
parameters that are available for the link.

Peter

---

From: Christian M. Amsüss <[email-masked]>
Date: Tue, 17 Apr 2018 17:25:59 +0200

On Sun, Apr 15, 2018 at 11:47:32AM -0700, Jim Schaad wrote:
> Carsten Bormann wrote:
> I would agree that I would not have read this as needing to have two
> "?" characters in the query parameters.  My issue is that I worry
> about the case that an RD decides to use foo=XXX as the location query
> and then some application decides to use foo as a query parameter in
> the extra parameters or in a link description.  This works fine on RD
> implementation #1 because it is just using a location path to point to
> the end point, but when it hits RD implementation #2 which is using
> the location query as well it starts failing.  

There would not be a conflict with use in links descriptions, but still
would be with extra parameters in a registration update.

On those grounds I'll propose a text to rule out query parameters.

Thanks
Christian

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Apr 2018 17:50:02 +0200

Hi Jim,

> Doing this is going to make my life as an implementor really a mess.  I will no longer be able to simply have a single representation of the internal data structure and do the parsing as serialization to a common format.  I am now going to need to remember what the original representation was and do the serializations differently based on that value.   In addition to this, all of my internal calls to setup the link format to begin with need to have this distinction so that things get serialized correctly.  

That would indeed be a disaster, and I thought we can avoid all of this.  
My assumption was that we can move forward the data model while staying compatible with the older serialization.

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

If we don’t want to carry forward the idiosyncrasies of link-format to JSON/CBOR, that is the inevitable result.  
But this should be doable with a small piece of code in the serializer, not by having two different data models.

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 17 Apr 2018 18:40:17 +0200

Hello Carsten, hello Jim,

> (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