Draft: draft-ietf-core-resource-directory

Commentary: Contributes - To : 
 Hi  , thanks for this addition . a few textual changes . why link - format resources and not just /.well - known / core ?   text 
 I said " link - format " because self - description data may be hosted in other ct="40 " resources linked at .well - known / core -- but that 's a detail I do n't think we have to consider here ; pull request is updated . 
 If we agree on some basic principles RD should follow , we can phrase them into a text that both guides other decisions in the RD design and can help implementers understand the basic ideas . As I understand , those can be Statements obtained from the RD should stem from statements that can be found on the origin device ( on .well - known / core or other ct=40 resources linked by it ) . As of -10 , this is compatible but not enforced in resource links , and absent in statements about the whole device ( where registration query parameters ep , et and d are exposed as resource attributes in the endpoint lookup ) I 'd treat commissioning tools that store information on behalf of the too - constrained origin node as an exception here . Another possible exception is the RD ( or something interacting with it ) making more statements true , eg . by registering the nodes 's address in the DNS and thus making a resolvable ( and possibly more stable ) name available for use in con . An RD registration can only be updated using the registration resource ( which typically only the origin device knows ) . If some entity ( eg . a DNS - SD bridge ) wants to update a resource 's description ( eg . change an instance name or rename an endpoint ) , they have to find ( possibly through the RD ) if and where the origin server allows such modification , and put the changes there . Are those agreeable principles , and what else belongs in that category ? 
 During the last calls , it has emerged that RD is seen as an optimization of multicast discovery on .well - known / core ; this can probably be merged with the first item above . 
 I do n't see the CT as an exception ; I reformulated that aspect .
Paragraph (version A):
The Resource Directory is primarily a tool that enables discovery
operations that are already present for CoRE devices to happen more
efficiently, or across boundaries that would be limiting those
operations.
Paragraph (version A):
It provides a cache (in the high-level sense, not as defined in
RFC7252/RFC2616) of data that could otherwise only be obtained by
directly querying the link-format resources on the target device, or
by accessing those resources with a multicast request.
Paragraph (version A):
From that, it follows that no information should be stored in the
resource directory that can not be discovered from querying the
described device's link-format resources directly.
Paragraph (version A):
It also follows that data in the resource directory can only be
provided by the device whose descriptions are cached.  (Commissioning
tools are an exception here because they are thought to act on behalf
agents too constrained to present that information themselves).  No
other client can modify data in the resource directory or even expect
those changes to propagate back to its source.
Paragraph (version B):
The Resource Directory is primarily a tool to make discovery
operations more efficient than querying /.well-known/core on all
connected device, or across boundaries that would be limiting those
operations.
Paragraph (version B):
It provides a cache (in the high-level sense, not as defined in
RFC7252/RFC2616) of data that could otherwise only be obtained by
directly querying the /.well-known/core resource on the target
device, or by accessing those resources with a multicast request.
Paragraph (version B):
From that, it follows that no information should be stored in the
resource directory that cannot be discovered from querying the
described device's /.well-known/core resource directly.
Paragraph (version B):
It also follows that data in the resource directory can only be
provided by the device whose descriptions are cached or a dedicated
Commissioning Tool (CT).  These CTs are thought to act on behalf
agents too constrained, or generally unable, to present that
information themselves.  No other client can modify data in the
resource directory or even expect those changes to propagate back to
its source.