[core] Use of rel=hosts (LWM2M?)

[Christian Amsüss]

Hello CoRE mailing list,

the semantics of rel="hosts" came up in recent RD planning discussions
(around the topic of "how are statements from .well-known/core correctly
represented in the RD?").

What is the relation type used for, and are any particular semantics
applied to it, especially in LWM2M which was mentioned as one
application area?

The description in RFC6690 doesn't say too much, and rumor has it it is
used to determine which host to contact for reaching the resource. Could
someone elaborate on any application it has, or give me a pointer to
where such applications are described further?

Thanks
Christian

[Klaus Hartke]

Post by Christian Amsüss
the semantics of rel="hosts" came up in recent RD planning discussions
(around the topic of "how are statements from .well-known/core correctly
represented in the RD?").
What is the relation type used for, and are any particular semantics
applied to it, especially in LWM2M which was mentioned as one
application area?
The description in RFC6690 doesn't say too much, and rumor has it it is
used to determine which host to contact for reaching the resource. Could
someone elaborate on any application it has, or give me a pointer to
where such applications are described further?

Originally, RFC6690 was only for the /.well-known/core resource. A
/.well-known/core resource of a server consists of links to the
resources hosted by the server: the server "hosts" the link targets.

In practice, the "hosts" relation type is basically a "I'm told I must
use link relation types; let's put some random string in the 'rel'
field to make people happy and then completely ignore it".

I guess a resource directory is more like a repository of URLs (with
some resource metadata) rather than of links, since there isn't really
a relationship between the RD and the resources other than that the RD
stores their URLs.

Klaus

[Christian Amsüss]

Hello Klaus and WG,

Post by Klaus Hartke
Originally, RFC6690 was only for the /.well-known/core resource. A
/.well-known/core resource of a server consists of links to the
resources hosted by the server: the server "hosts" the link targets.
In practice, the "hosts" relation type is basically a "I'm told I must
use link relation types; let's put some random string in the 'rel'
field to make people happy and then completely ignore it".

Thanks for your reply, this sounds quite plausible to me.

One perspective I've recently started to take is that 'hosts' allows
applications to group resources of a device together even though URIs
are opaque to it -- but that goes well together with yours.


Another different use of 'hosts' I've heard of happens in some versions
of (or plans for) OCF, where the target should be interpreted relative
to the anchor if (and only if) rel=hosts. This is a use case of which I
think it contradicts the resolution rules of RFC6690 (and would be
better served by protocol-negotiation) -- but if this is interpretation
is more widespread (or deployed anywyhere), we should probably work out
together how this fits with the rest of the link-format model.

Is it?

Post by Klaus Hartke
I guess a resource directory is more like a repository of URLs (with
some resource metadata) rather than of links, since there isn't really
a relationship between the RD and the resources other than that the RD
stores their URLs.

We're trying to store the link in its full semantics in the RD, not only
the targets (so eg. <http://example.com/temp.html>;anchor="/temp";
rel="describedby" can be understood by a client to the RD). From the
document's current (and probably also WGLC) state, this means that the
hosts relationship is carried over as a </temp>;if="core.s";
anchor="coap://the-endpoint", still keeping the implied hosts
relationship.

Best regards
Christian

[Klaus Hartke]

Post by Christian Amsüss

Post by Klaus Hartke
I guess a resource directory is more like a repository of URLs (with
some resource metadata) rather than of links, since there isn't really
a relationship between the RD and the resources other than that the RD
stores their URLs.

We're trying to store the link in its full semantics in the RD, not only
the targets (so eg. <http://example.com/temp.html>;anchor="/temp";
rel="describedby" can be understood by a client to the RD). From the
document's current (and probably also WGLC) state, this means that the
hosts relationship is carried over as a </temp>;if="core.s";
anchor="coap://the-endpoint", still keeping the implied hosts
relationship.

I grouped those "describedby" links into "resource metadata".

For example, if you store something like this
<coap://example.com/.well-known/core> representation (taken from RFC6690)

</sensors>;ct=40;title="Sensor Index",
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
<http://www.example.com/sensors/t123>;anchor="/sensors/temp"
;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate"

in a resource directory, then the RD essentially stores these URLs

<coap://example.com/sensors>
<coap://example.com/sensors/temp>
<coap://example.com/sensors/light>

together with this resource metadata

<coap://example.com/sensors>
* ct=40
* title="Sensor Index"

<coap://example.com/sensors/temp>
* rt="temperature-c"
* if="sensor"
* link rel="describedby" href="http://www.example.com/sensors/t123"
* link rel="alternate" href="coap://example.com/t"

<coap://example.com/sensors/light>
* rt="light-lux"
* if="sensor"

It would make a lot of sense to make the target URLs of the inner
links relative to the outer URLs. And to be able to specify a base URL
for the top-level URLs. Something like this:

#base <coap://example.com/>

</sensors> {
ct "40"
title "Sensor Index"
}

</sensors/temp> {
rt "temperature-c"
if "sensor"
describedby <http://www.example.com/sensors/t123>
alternate </t>
}

</sensors/light> {
rt "light-lux"
if "sensor"
}

Klaus