Subject: [core] Links, hosts, and resource directories

From: Klaus Hartke <[email-masked]>
Date: Sat, 27 Oct 2018 12:55:46 +0200

draft-ietf-core-resource-directory-17 [1] says:

   [A Resource Directory (RD)] hosts registrations of
   resources held on other servers, allowing lookups
   to be performed for those resources.

Is this a lie?

I'm confused.

Example time!

In the following, I'm using URI references [2] in angle brackets --
like <coap://example.com/foo> -- to denote a reference to a resource
and a 3-tuple -- like (coap,example.com,5683) -- to denote a Web
origin [3]. Note that <coap://example.com/> references the resource at
the root in the hierarchy of the endpoint (coap,example.com,5683), not
the endpoint. Let `$origin(x)` be a function that returns the Web
origin for a given URI `x`.

Let's say we have an endpoint (coap,example.com,5683) that has three
resources: <coap://example.com/foo>, <coap://example.com/bar>, and
<coap://example.com/baz>. The endpoint wishes to enable resource
discovery [4], so it provides another resource
<coap://example.com/.well-known/core> with the following
representation in Link Format [5]:

    <coap://example.com/foo>;rt=a,<coap://example.com/bar>;rt=b,<coap://example.com/baz>;rt=a

This means, there are three links [6]:

   <coap://example.com/.well-known/core>  hosts
          <coap://example.com/foo>  which has type "a" .
   <coap://example.com/.well-known/core>  hosts
          <coap://example.com/bar>  which has type "b" .
   <coap://example.com/.well-known/core>  hosts
          <coap://example.com/baz>  which has type "a" .

The link context of each link is the represented resource. The link
relation type is implicitly the default value for "rel" in Link
Format, "hosts". The link target is the referenced resource.

Because the "hosts" link relation type is weird, these three links are
actually not links but the following statements:

   $origin(<coap://example.com/.well-known/core>)  has a resource
          <coap://example.com/foo>  which has type "a" .
   $origin(<coap://example.com/.well-known/core>)  has a resource
          <coap://example.com/bar>  which has type "b" .
   $origin(<coap://example.com/.well-known/core>)  has a resource
          <coap://example.com/baz>  which has type "a" .

or, in other words:

   (coap,example.com,5683)  has a resource  <coap://example.com/foo>
          which has type "a" .
   (coap,example.com,5683)  has a resource  <coap://example.com/bar>
          which has type "b" .
   (coap,example.com,5683)  has a resource  <coap://example.com/baz>
          which has type "a" .

This is totally redundant, because $origin(<coap://example.com/foo>)
is (coap,example.com,5683) as well. So the statements don't provide
any information that cannot already be derived from the resource
identifiers directly.

Ignoring this cognitive dissonance, if the endpoint now wishes to
enable resource discovery through a directory, the idea is that it can
upload the representation of its <coap://example.com/.well-known/core>
to this directory, allowing other nodes to perform lookups.

There seem to be two ways to model this: either as a directory of
resources or as a directory of links.

Asking a directory of resources at <coap://rd.example/> for resources
of type "a" should give a list of links from the directory to matching
resources:

    <coap://rd.example/>  contains a registration for
          <coap://example.com/foo>  which has type "a" .
    <coap://rd.example/>  contains a registration for
          <coap://example.com/baz>  which has type "a" .

or, in Link Format:

    <coap://example.com/foo>;rel=item;rt=a,<coap://example.com/baz>;rel=item;rt=a

Asking a directory of links at <coap://ld.example/> for links to
resources of type "a" should give a list of matching links:

   (coap,example.com,5683)  has a resource  <coap://example.com/foo>
          which has type "a" .
   (coap,example.com,5683)  has a resource  <coap://example.com/baz>
          which has type "a" .

or, in Link Format:

    <coap://example.com/foo>;rel=hosts;rt=a;anchor="coap://example.com/.well-known/core",<coap://example.com/baz>;rel=hosts;rt=a;anchor="coap://example.com/.well-known/core"

After skimming through draft-ietf-core-resource-directory [1] and the
interop spec [7] a few times, it's not clear to me whether the draft
describes a resource directory or a link directory, as none of the
examples seem to match my examples above.

Am I completely off?

Is it a lie that a resource directory allows lookups of resources; is
it for lookups of links? Isn't the interop spec fundamentally broken
then?

And why does the "hosts" link relation type have to be so weird?

Klaus

[1] https://tools.ietf.org/html/draft-ietf-core-resource-directory-17
[2] https://tools.ietf.org/html/rfc3986#section-4.1
[3] https://tools.ietf.org/html/rfc6454#section-4
[4] https://tools.ietf.org/html/rfc7252#section-7.2
[5] https://tools.ietf.org/html/rfc6690#section-2
[6] https://tools.ietf.org/html/rfc8288#section-2
[7] http://htmlpreview.github.io/?https://github.com/core-wg/resource-directory/blob/a978f7c2e89fa97daea967716765a798bbfda4e8/interop-spec.html

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Oct 2018 16:17:52 +0200

On Oct 27, 2018, at 12:55, Klaus Hartke <[email-masked]> wrote:
> is (coap,example.com,5683) as well. 

This would be redundant if we already knew that there is a /foo on that origin (and if we also knew that it has rt=“a”).
But we don’t, so the RD entry is useful.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 27 Oct 2018 17:10:35 +0200

Thanks for helping to clarify, Carsten!

Klaus

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 29 Oct 2018 09:10:24 +0100

Hi Klaus,

I am not clear what your suggestion is.
The registration is a concept local to the resource directory.
Indeed, the registration contains information about resources located at
other servers than the Resource Directory.
Where is this text misleading? I will be happy to remove confusions.

Peter
Klaus Hartke schreef op 2018-10-27 12:55:

> draft-ietf-core-resource-directory-17 [1 [1]] says:
> 

Links:
------

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 30 Oct 2018 17:28:22 +0100

Peter van der Stok wrote:
> Indeed, the registration contains information about resources located at other servers than the Resource Directory.

I'm requesting clarification on how these registrations look like. The
introduction is giving the impression that the server is managing
registrations as a "directory of resources", while the remaining draft
is giving more the impression of a "directory of links", which is
contradicted by the interop spec that again is giving the impression
of a "directory of resources" but not consistently. In particular, I'm
confused by the two examples from the interop spec that Jim tried to
translate [1] to CoRAL, as these don't look like something a server
would ever generate and thus are not very illuminative when translated.

Klaus

[1] https://www.ietf.org/mail-archive/web/core/current/msg09996.html

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 31 Oct 2018 07:59:40 +0100

Hello Klaus,

>    to be performed for those resources.

Without more context, yes it is, and we should ensure that the wording
does not lead to the conclusion that resources (and not links) would be
stored.

(Historically, the most up to date description is in the principles
section, and at least of myself I can say that I was more focused on the
rest of the text than the abstract.)

What is registered at an RD are links, which happen to also describe
resources.

I think that should answer the core of the issue, some detailed answeres
below if still interested.

Thanks
Christian

PS.: some more point-to-point details

>           <coap://example.com/foo>  which has type "a" .

Actually it is `<coap://example.com> hosts ...` due to the wording of
RFC6690 Section 2.1 b).

> any information that cannot already be derived from the resource

Providing the link and not only the resource with its target attributes
is indeed redundant here, but the RD can and should IMO not try to make
anything of relation types.

I'm not sure that this interpretation of 'hosts' necessarily follows
from the definition ("hosted by the server indicated by the link
context").  Personally I perfer to think of it as having no more meaning
than "Two resources are co-hosted if both have a 'hosts' from the same
URI", for lack of a semantic applicability of the Origin concept (AFAIR
that concept is defined solely for the purpose of browser security).

> And why does the "hosts" link relation type have to be so weird?

My guess would be that having a default relation was an idea from
initial consultations with "web linking people", and then became RFC6690
in a process more guided by concrete ideas of CoAP URIs than by typed
links and the RDF data model.

>           <coap://example.com/foo>  which has type "a" .

The statement would rather be (and there were late changes to the
interop specs b/c the added anchor was missed in the original one):

>     <coap://example.com>  hosts

There is, in terms of links, no relation to the RD or its lookup
resource other than that the lookup resource makes the statement
available. It could be tied to a registration within the RD by looking
up the statement at the endpoint interface and querying registrations
provide it (and those registrations would be hosted by the RD), but
that's only the management part.

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

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 31 Oct 2018 09:13:53 +0100

Christian Amsüss schreef op 2018-10-31 07:59:

Hello Klaus,

On Sat, Oct 27, 2018 at 12:55:46PM +0200, Klaus Hartke wrote:   [A
Resource Directory (RD)] hosts registrations of
   resources held on other servers, allowing lookups
   to be performed for those resources.

Is this a lie?

Sorry to react to this, but
I cannot imagine how "registrations of resources" can be equated with
"resources".

But if it creates confusion it needs to be adapted.

would "RD registers information about resources on other servers" be
better?
Followed by: "The registration uses as input links, and the lookup
returns links, where the returned link is constructed from the
information stored in the RD."

Peter