Subject: [core] Resouce Directory - generic base URIs (con / anchor)

From: "Kovatsch, Matthias" <[email-masked]>
Date: Fri, 20 Apr 2018 16:00:43 +0000

Dear list

RD allows the "con" parameter to provide a base URI for relative resource URIs, when the registration is done from a different source address then the registered endpoint itself. "con" is restricted to the scheme and authority part of a URI, that is, no path segments are allowed. This came from the assumption that all CoRE devices will naturally correlate with socket-address endpoints.

However, a registered device(=endpoint, "ep") might not be a natural endpoint. When using gateways or device proxies, the base URI will have path segments and multiple logically different endpoints will share the same socket-address (e.g., coaps://gw.example.com/dev/d1, coaps://gw.example.com/dev/d2, coaps://gw.example.com/dev/d3).

This makes it expensive to move such logical endpoints, as updating "con" will not help. All links have to be removed, changed to the new prefix, and registered anew.

This is a problem for some applications (including a bigger alliance using CoAP), in particular because the patch mechanism is still to be defined - yet rewriting URI prefixes still will not be really efficient even when having patch registration updates.

I thus propose to generalize "con" to be any base URI that will be applied to all relative links an endpoint registered.
If there is a conflict with a deployed mechanism, we could look into adopting "anchor" and let RD use it similarly to "con", but allowing full base URIs (including paths).
Or we align with RFC 8288 altogether and replace "con" with "anchor": https://tools.ietf.org/html/rfc8288#section-3.2

Ciao,
Matthias

---

From: 'Christian Amsüss' <[email-masked]>
Date: Fri, 20 Apr 2018 22:49:57 +0200

Hello Matthias,

thanks for bringing this to the list.

On Fri, Apr 20, 2018 at 04:00:43PM +0000, Kovatsch, Matthias wrote:
> I thus propose to generalize "con" to be any base URI that will be
> applied to all relative links an endpoint registered.  If there is a
> conflict with a deployed mechanism, we could look into adopting
> "anchor" and let RD use it similarly to "con", but allowing full base
> URIs (including paths).

We had considered that briefly but found it'd be too difficult for
implementors for too little use cases; as you do describe use cases, we
might reconsider it.

The ugly thing about is: Registrations that are sent in
application/link-format can not make use of a path component in the Base
URI (which the con is), because RFC6690's resolution rules strip away
the Base URI's path component by using Origin terminology.

That means that registrations that would use such a con would in
practice need to use a content format that does not use RFC6690
resolution rules, and right now it is still under discussion whether
links-json will be safe from that.

The references in the registration body would all need to be in
path-noscheme or path-empty form. (And given that link rewriting in
proxies is a fragile thing in general, devices using that should not use
path-absolut form anywhere).

Would that still work for you?

> If there is a conflict with a deployed mechanism, we could look into
> adopting "anchor" and let RD use it similarly to "con", but allowing
> full base URIs (including paths).
>
> Or we align with RFC 8288 altogether and replace "con" with "anchor":
> https://tools.ietf.org/html/rfc8288#section-3.2

We do use anchor for what RFC8288 intends it for: the Link Context
(where the link points from), which is faithfully expressed from what
is submitted in the registration. con does something different in that
it provides a Base URI to the representation transported in the
registering POST. RFC6690 has an unfortunate convolution of those
things, but RFC8288 keeps them neatly separate.

Best regards
Christian

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

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 23 Apr 2018 12:11:39 +0000

> thanks for bringing this to the list.

Sure :)

> The ugly thing about is: Registrations that are sent in application/link-format can not make use of a path component in the Base URI
> (which the con is), because RFC6690's resolution rules strip away the Base URI's path component by using Origin terminology.

But the current "con" is already shadowing the Origin.
I am currently missing the time to look it up myself: Does link-format enforce absolute path URIs (i.e., starting with "/")?

> That means that registrations that would use such a con would in practice need to use a content format that does not use RFC6690
> resolution rules, and right now it is still under discussion whether links-json will be safe from that.

Sounds like one more reason to have a proper links-json format that ignores link-format baggage :)

> The references in the registration body would all need to be in path-noscheme or path-empty form. (And given that link rewriting in
> proxies is a fragile thing in general, devices using that should not use path-absolut form anywhere).
> 

I am not sure, I can follow here. My proposal would assume either absolute or relative URIs in the registration body. All relative URIs are resolved using the "con" base URI, following the URI RFC algorithm.

"con" would be used by tools that register on behalf of devices. Such tools must talk to the RD directly. If they go through a proxy that does re-write magic to the body, then it is of course messing up the information and it is the fault of whoever deployed that proxy.

> We do use anchor for what RFC8288 intends it for: the Link Context (where the link points from), which is faithfully expressed from what
> is submitted in the registration. con does something different in that it provides a Base URI to the representation transported in the
> registering POST. RFC6690 has an unfortunate convolution of those things, but RFC8288 keeps them neatly separate.

I can see how this got messy when thinking about relative URIs...
Anyhow, let's fix "con" then.

Ciao,
Matthias