Draft: draft-ietf-core-resource-directory

Commentary: Thanks , merged . ( If questions come up around the normative - language RECOMMENDED : I agere that from the capitals NOT before it , this was already intended to be normative . )
Paragraph (version A):
This and the following sections define the required set of REST
interfaces between an RD, endpoints and lookup clients.  Although the
examples throughout these sections assume the use of CoAP RFC7252,
these REST interfaces can also be realized using HTTP RFC7230.  Only
multicast discovery operations are not possible on HTTP, and Simple
Registration can not be executed as base attribute (which is
mandatory for HTTP) can not be used there.  In all definitions in
these sections, both CoAP response codes (with dot notation) and HTTP
response codes (without dot notation) are shown.  An RD implementing
this specification MUST support the discovery, registration, update,
lookup, and removal interfaces.
Paragraph (version B):
This and the following sections define the required set of REST
interfaces between an RD, endpoints and lookup clients.  Although the
examples throughout these sections assume the use of CoAP RFC7252,
these REST interfaces can also be realized using HTTP RFC7230.  Only
multicast discovery operations are not possible on HTTP, and Simple
Registration can not be executed as the base attribute (which is
mandatory for HTTP) can not be used there.  In all definitions in
these sections, both CoAP response codes (with dot notation) and HTTP
response codes (without dot notation) are shown.  An RD implementing
this specification MUST support the discovery, registration, update,
lookup, and removal interfaces.
Paragraph (version A):
From a management and maintenance perspective, it is necessary to
identify the components that constitute the RD server.  The
identification refers to information about for example client-server
incompatibilities, supported features, required updates and other
aspects.  The URI discovery address, a described in section 4 of
RFC6690 can be used to find the identification.
Paragraph (version B):
From a management and maintenance perspective, it is necessary to
identify the components that constitute the RD server.  The
identification refers to information about for example client-server
incompatibilities, supported features, required updates and other
aspects.  The URI discovery address, as described in section 4 of
RFC6690 can be used to find the identification.
Paragraph (version A):
Above rules allow the client to interpret the response as links
without any further knowledge of the storage conventions of the RD.
The RD MAY replace the registration base URIs with a configured
intermediate proxy, e.g. in the case of an HTTP lookup interface for
CoAP endpoints.
Paragraph (version B):
The above rules allow the client to interpret the response as links
without any further knowledge of the storage conventions of the RD.
The RD MAY replace the registration base URIs with a configured
intermediate proxy, e.g. in the case of an HTTP lookup interface for
CoAP endpoints.
Paragraph (version A):
Note that "href" is a valid search criterion and matches target
references.  Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it.  Queries
for resource link targets MUST be in URI form (i.e. not relative
references) and are matched against a resolved link target.  Queries
for endpoints SHOULD be expressed in path-absolute form if possible
and MUST be expressed in URI form otherwise; the RD SHOULD recognize
either.  The "anchor" attribute is usable for resource lookups, and,
if queried, MUST be for in URI form as well.
Paragraph (version B):
Note that "href" is a valid search criterion and matches target
references.  Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it.  Queries
for resource link targets MUST be in URI form (i.e. not relative
references) and are matched against a resolved link target.  Queries
for endpoints SHOULD be expressed in path-absolute form if possible
and MUST be expressed in URI form otherwise; the RD SHOULD recognize
either.  The "anchor" attribute is usable for resource lookups, and,
if queried, MUST be in URI form as well.
Paragraph (version A):
As above, the impact of undesirable links depends on the extent to
which the lookup client relies on the RD.  To avoid the limitations,
RD applications should consider prescribe that lookup clients only
use the discovered information as hints, and describe which pieces of
information need to be verified with the server because they impact
the application's security.
Paragraph (version B):
As above, the impact of undesirable links depends on the extent to
which the lookup client relies on the RD.  To avoid the limitations,
RD applications should consider prescribing that lookup clients only
use the discovered information as hints, and describe which pieces of
information need to be verified with the server because they impact
the application's security.