[core] Links, hosts, and resource directories

Klaus Hartke <hartke@projectcool.de> Sat, 27 October 2018 10:56 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 24448130E4F for <core@ietfa.amsl.com>; Sat, 27 Oct 2018 03:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yJcnIrrBaF0L for <core@ietfa.amsl.com>; Sat, 27 Oct 2018 03:56:21 -0700 (PDT)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB33E130DE4 for <core@ietf.org>; Sat, 27 Oct 2018 03:56:20 -0700 (PDT)
Received: from mail-qt1-f176.google.com ([]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gGMGP-0008DR-4K; Sat, 27 Oct 2018 12:56:17 +0200
Received: by mail-qt1-f176.google.com with SMTP id l9-v6so4120415qtj.12 for <core@ietf.org>; Sat, 27 Oct 2018 03:56:17 -0700 (PDT)
X-Gm-Message-State: AGRZ1gIRWWDIiLVR4n7lt6R+yU5RIakNgAkncofBXKXCMIOBrgYqZsG9 U3LLns+DDQ9mDtdQ0Y4wfOeWtsoFW23mwxZvAzQ=
X-Google-Smtp-Source: AJdET5d5tEfq+Nq4ALPfhcb9ZXCky1v2lYpaDLZdlZPt9P3EyV1TmFYcaQWyY6XQqysKuq2JcssWiF4kjXPL6O7OM68=
X-Received: by 2002:ac8:16e4:: with SMTP id y33-v6mr6510248qtk.253.1540637776034; Sat, 27 Oct 2018 03:56:16 -0700 (PDT)
MIME-Version: 1.0
From: Klaus Hartke <hartke@projectcool.de>
Date: Sat, 27 Oct 2018 12:55:46 +0200
X-Gmail-Original-Message-ID: <CAAzbHvZP-XfjFSn0p++9ECY8LAFaVaBrYhmnyNKW1SQOnR6cOw@mail.gmail.com>
Message-ID: <CAAzbHvZP-XfjFSn0p++9ECY8LAFaVaBrYhmnyNKW1SQOnR6cOw@mail.gmail.com>
To: "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1540637780; 93972e90;
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/CW0eKCtISPFJUmHQmkuUXD31iUo>
Subject: [core] Links, hosts, and resource directories
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Oct 2018 10:56:23 -0000

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


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

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


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:


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

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


[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