[core] Report on first Resource Directory plugtest

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

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.