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

[Kovatsch, Matthias]

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

['Christian Amsüss']

Hello Matthias,

thanks for bringing this to the list.

Post by Kovatsch, Matthias
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?

Post by Kovatsch, Matthias
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).
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

[Kovatsch, Matthias]

Post by 'Christian Amsüss'
thanks for bringing this to the list.

Sure :)

Post by 'Christian Amsüss'
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 "/")?

Post by 'Christian Amsüss'
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 :)

Post by 'Christian Amsüss'
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?

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.

Post by 'Christian Amsüss'

Post by Kovatsch, Matthias
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).
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.

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

Ciao,
Matthias