Draft: draft-ietf-core-resource-directory

Commentary: This allows for gateway devices that register their mapped legacy devices individually . Closes : 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 do n'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 does n'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 should n'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 obsolete , as those components would be allowed ) . ( and possibly I 'd assume you wo n't be too happy with ( based on previous discussions of that topic ) , but do you see  ' 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 do n'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 ( a " no we ca n't have that because " would be more appreciated today than later ) , let 's talk about again when we have that .
Paragraph (version A):
A Context is a base URL that gives scheme and (typically)
authority information about an Endpoint.  The Context of an
Endpoint is provided at registration time, and is used by the
Resource Directory to resolve relative references inside the
registration into absolute URIs.  This is a distinct concept from
the "link context" defined in RFC8288.
Paragraph (version B):
A Context is a base URL that typically gives scheme and authority
information about an Endpoint.  The Context of an Endpoint is
provided at registration time, and is used by the Resource
Directory to resolve relative references inside the registration
into absolute URIs.  This is a distinct concept from the "link
context" defined in RFC8288.
Paragraph (version A):
Context (optional).  This parameter sets the Default Base URI
under which the request's links are to be interpreted.  The
specified URI MUST NOT have a path component of its own, but
MUST be suitable as a base URI to resolve any relative
references given in the registration.  The parameter is
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.
Paragraph (version B):
Context (optional).  This parameter sets the Default Base URI
under which the request's links are to be interpreted.  The
specified URI typically does not have a path component of its
own, and MUST be suitable as a base URI to resolve any relative
references given in the registration.  The parameter is
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.