Code change:
This allows for gateway devices that register their mapped legacy devices individually. Closes: URL The delta is smaller than I expected because at some places, paths were already allowed (eg. in the IANA table for "con"). One place where I'm unsure if we should change it because I don't know what it actually means is the "scheme, IP, port" annotation in fig-hierarchy -- what does it mean there?
what is a path no scheme form? An example might help here.
path-noscheme form is one of the possible ABNF forms for a relative reference from ; it basically means "relative references that does not even start with a slash". I'm conflicted about having an example in the draft (our examples already feel like a test suite), but I'll give one here and we can still consider moving it in: ~
Merging this with a clarification for the ABNF item, so we have a single version to talk about later today.
I'm aware this is a discussion we've already had, but back then we dropped it for its complexity and because we had no use cases. Matthias has brought up use cases for allowing a path in the con as part of the -13 reviews. He argues that a gateway bridging into a non-CoAP world would want to register its proxees (is that a word?) individually, and if it doesn't use name-based virtual hosting (which is kind of rare in CoAP and needs wildcard DNS records), could go for path-based hosting. As I see it, this would be a trivial addition from the RD point of view ("just allow it"). The onus is on the endpoint / gateway to do it right, ie. to never use path-absolute URI references unless they mean it. What does make this a bit more complicated is that none of the content formats we currently describe allows using that meaningfully -- but we are not limiting the RD to those content formats, and they may (and hopefully will) still change while we're finishing RD. On the editing track, I would keep those cases out of the examples (I'm game for building a test suite, but the examples shouldn't be that). Then, the editing becomes a matter of replacing "specified URI MUST NOT have a path component" with "typically does not have a path component", adding the one or the other "typically", and being done with it. (This would also make URL obsolete, as those components would be allowed). NAME (and possibly NAME I'd assume you won't be too happy with (based on previous discussions of that topic), but do you see Matthias' point, or could point out concrete issues you see from allowing this?
I would prefer that not be made obsolete on this. You should be able to have a URI w/ a path and a relative URI which are then combined. If we need to combine things like query parameters then it is going to get really messy really fast because there are not good rules about that. I don't have any problems w/ allowing for the con to have a path and resolving with it. I just think that we need to establish what the rules are in the RD document rather than using the horrible link format rules.
There are very good rules about that query parts and fragments in the Base URI: Anything that is not an empty string or starts with a "#" removes the fragment identifier and the query parameters. The Base URI's fragment identifier is never kept. (Derived from RFC3986 Section 5.2). I'll try to write text on this issue on the weekend (NAME a "no we can't have that because" would be more appreciated today than later), let's talk about again when we have that. 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., URL, URL, URL). 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": URL Ciao, Matthias

Related discussion:
text: Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the