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

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

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
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>;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" .

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

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

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://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
>           <coap://example.com/foo>  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