Code change:
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

Related discussion:
text: 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.