Draft: draft-ietf-core-resource-directory

Commentary: All URIs of RD APIs are discovered standalone , and no relative URI or path - appending is required any more . Therefore , the term " Base URIs " and the distinction between " rd - lookup - base " and " lookup - type " in the RD lookup API are obsolete . This has already been , and , if I understood his response correctly ( which I 'm unsure about , thus tagging this for review ) . 
 I 'd consider toning down the default value recommendations a different issue ; is it fine with you apart from that ? ( Note to self : I accidentally dropped the " res:= " parameter here ; that 's another topic and should n't go in that commit . ) 
 There is still some weirdness here : The " URIs " here are still parameters for URI templates , not the actual URIs that will be used for accesses . 
 Good point . Going from to should address that , I 'll update accordingly . 
 I 've updated the pull request to address the comments , and fixed some oversights of mine . While the first commit has been modified , the changes should largely be review friendly in that the three last commits are the newly introduced ones for template weirdness " recommended " → " example " rewording and some more " base " occurrences I had missed , together with clearer naming of the " RD registration URI " instead of just "  ( base ) URI " which might cause confusion with the " RD URIs " ( the " RD lookup URIs " and the " RD group URI " ) in general . 
 Merged as agreed in last call . 
 It is argued that a recommended base path is not appropriate . At line 593 : " the value /rd is recommended " , should be : " the value /rd is an example value " .
Paragraph (version A):
Discovery of the RD URI paths is performed by sending either a
multicast or unicast GET request to "/.well-known/core" and including
a Resource Type (rt) parameter RFC6690 with the value "core.rd" in
the query string.  Likewise, a Resource Type parameter value of
"core.rd-lookup*" is used to discover the base URI for RD Lookup
operations, and "core.gp" is used to discover the URI path for RD
Group operations.  Upon success, the response will contain a payload
with a link format entry for each RD function discovered, indicating
the URI path of the RD function returned and the corresponding
Resource Type.  When performing multicast discovery, the multicast IP
address used will depend on the scope required and the multicast
capabilities of the network.
Paragraph (version B):
Discovery of the RD registration URI path is performed by sending
either a multicast or unicast GET request to "/.well-known/core" and
including a Resource Type (rt) parameter RFC6690 with the value
"core.rd" in the query string.  Likewise, a Resource Type parameter
value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
operations, and "core.gp" is used to discover the URI path for RD
Group operations.  Upon success, the response will contain a payload
with a link format entry for each RD function discovered, indicating
the URI path of the RD function returned and the corresponding
Resource Type.  When performing multicast discovery, the multicast IP
address used will depend on the scope required and the multicast
capabilities of the network.
Paragraph (version A):
The following example shows an endpoint discovering an RD using this
interface, thus learning that the base RD resource is, in this
example, at /rd and that the content-format delivered by the server
hosting the resource is application/link-format (ct=40).  Note that
it is up to the RD to choose its RD resource paths.
Paragraph (version B):
The following example shows an endpoint discovering an RD using this
interface, thus learning that the RD registration resource is, in
this example, at /rd, and that the content-format delivered by the
server hosting the resource is application/link-format (ct=40).  Note
that it is up to the RD to choose its RD resource paths.
Paragraph (version A):
The following example shows the way of indicating that a client may
request alternate content-formats.  The Content-Format code attribute
"ct" MAY include a space-separated sequence of Content-Format codes
as specified in Section 7.2.1 of RFC7252, indicating that multiple
content-formats are available.  The example below shows the required
Content-Format 40 (application/link-format) indicated as well as a
more application-specific content format (picked as 65225 in this
example; this is in the experimental space, not an assigned value).
The base RD resource values /rd, /rd-lookup, and /rd-group are
example values.  This server only implements some of the interfaces
described in this document.
Paragraph (version B):
The following example shows the way of indicating that a client may
request alternate content-formats.  The Content-Format code attribute
"ct" MAY include a space-separated sequence of Content-Format codes
as specified in Section 7.2.1 of RFC7252, indicating that multiple
content-formats are available.  The example below shows the required
Content-Format 40 (application/link-format) indicated as well as a
more application-specific content format (picked as 65225 in this
example; this is in the experimental space, not an assigned value).
The RD resource paths /rd, /rd-lookup, and /rd-group are example
values.  This server only implements some of the interfaces described
in this document.
Paragraph (version A):
RD URI (mandatory).  This is the location of the RD, as
obtained from discovery.
Paragraph (version B):
RD registration URI (mandatory).  This is the location of the
RD, as obtained from discovery.
Paragraph (version A):
The following example shows an EP registering a group with the name
"lights" which has two endpoints to an RD using this interface.  The
base location value /rd-group is an example RD location discovered in
a request similar to example-discovery.
Paragraph (version B):
The following example shows an EP registering a group with the name
"lights" which has two endpoints to an RD using this interface.  The
RD group path /rd-group is an example RD location discovered in a
request similar to example-discovery.
Paragraph (version A):
Access control SHOULD be performed separately for the RD
registration, Lookup, and group API base paths, as different
endpoints may be authorized to register with an RD from those
authorized to lookup endpoints from the RD.  Such access control
SHOULD be performed in as fine-grained a level as possible.  For
example access control for lookups could be performed either at the
domain, endpoint or resource level.
Paragraph (version B):
Access control SHOULD be performed separately for the RD
registration, Lookup, and group API paths, as different endpoints may
be authorized to register with an RD from those authorized to lookup
endpoints from the RD.  Such access control SHOULD be performed in as
fine-grained a level as possible.  For example access control for
lookups could be performed either at the domain, endpoint or resource
level.
Paragraph (version A):
LWM2M defines a registration interface based on the REST API,
described in rd.  The base URI path of the LWM2M Resource Directory
is specified to be "/rd".
Paragraph (version B):
LWM2M defines a registration interface based on the REST API,
described in rd.  The RD registration URI path of the LWM2M Resource
Directory is specified to be "/rd".