Draft: draft-ietf-core-resource-directory

Commentary: atomicity idempotency ,  multiple query parameter , Fairhair deleted eps from group ,  simple registration , hauke
Paragraph (version B):
All operations on the contents of the Resource Directory MUST be
atomic and idempotent.
Paragraph (version B):
A Resource Directory MUST accept query filtering with multiple query
parameters in the URI.
Paragraph (version A):
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 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.rd-group" 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):
An empty payload is considered a malformed request.
Paragraph (version A):
An endpoint that wants to make itself discoverable occasionally sends
a POST request to the "/.well-known/core" URI of any candidate
directory server that it finds.  The body of the POST request is
empty, which triggers the resource directory server to perform GET
requests at the requesting server's default discovery URI to obtain
the link-format payload to register.
Paragraph (version B):
An endpoint that wants to make itself discoverable sends (and
regularly refreshes with) a POST request to the "/.well-known/core"
URI of any candidate directory server that it finds.  The body of the
POST request is empty, which triggers the resource directory server
to perform GET requests at the requesting server's default discovery
URI to obtain the link-format payload to register.
Paragraph (version B):
The endpoints MUST be deleted after the expiration of their lifetime.
Additional operations cannot be executed because no registration
location is returned.
Paragraph (version A):
The update interface is used by an endpoint to refresh or update its
registration with an RD.  To use the interface, the endpoint sends a
POST request to the registration resource returned in the Location
header option in the response returned from the intial registration
operation.
Paragraph (version B):
The update interface is used by an endpoint to refresh or update its
registration with an RD.  To use the interface, the endpoint sends a
POST request to the registration resource returned in the Location
header option in the response returned from the intial registration
operation.  The POST request (in contrats to PUT) allows replacing
selection of a resource.
Paragraph (version B):
Removed endpoints are implicitly removed from the groups to which
they belong.
Paragraph (version A):
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola, Linyi Tian,
Chistian Amsuss, and Jan Newmarch have provided helpful comments,
discussions and ideas to improve and shape this document.  Zach would
also like to thank his colleagues from the EU FP7 SENSEI project,
where many of the resource directory concepts were originally
developed.
Paragraph (version B):
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Sampo
Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments,
discussions and ideas to improve and shape this document.  Zach would
also like to thank his colleagues from the EU FP7 SENSEI project,
where many of the resource directory concepts were originally
developed.