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

Christian Amsüss <> Wed, 31 October 2018 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E972126DBF for <>; Tue, 30 Oct 2018 23:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5k9rKz2DTig9 for <>; Tue, 30 Oct 2018 23:59:46 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B32531277BB for <>; Tue, 30 Oct 2018 23:59:46 -0700 (PDT)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id D51FC41D77; Wed, 31 Oct 2018 07:59:42 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id CC2DC74; Wed, 31 Oct 2018 07:59:41 +0100 (CET)
Received: from ( [IPv6:2a02:b18:c13b:8010::71b]) by (Postfix) with ESMTPSA id 670307A; Wed, 31 Oct 2018 07:59:41 +0100 (CET)
Received: (nullmailer pid 19235 invoked by uid 1000); Wed, 31 Oct 2018 06:59:40 -0000
Date: Wed, 31 Oct 2018 07:59:40 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Klaus Hartke <>
Cc: " WG" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [core] Links, hosts, and resource directories
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Oct 2018 06:59:50 -0000

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?

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

(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

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


PS.: some more point-to-point details

>     <coap://>;rt=a,<coap://>;rt=b,<coap://>;rt=a
> This means, there are three links [6]:
>    <coap://>  hosts
>           <coap://>  which has type "a" .

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

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

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://rd.example/>  contains a registration for
>           <coap://>  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://>  hosts
>           <coap://>  which has type "a" .

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