Change:
Contributes-To: URL
Hi Chris, thanks for this addition. a few textual changes. why link-format resources and not just /.well-known/core? Peter Proposed 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 don'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 don't see the CT as an exception; I reformulated that aspect.

Discussion:
3.1. <del> 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 </del> <ins> 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 </ins> operations. It provides a cache (in the high-level sense, not as defined in RFC7252/RFC2616) of data that could otherwise only be obtained by <del> directly querying the link-format resources on the target device, or by accessing those resources with a multicast request. </del> <ins> directly querying the /.well-known/core resource on the target device, or by accessing those resources with a multicast request. </ins> From that, it follows that no information should be stored in the <del> resource directory that can not be discovered from querying the described device's link-format resources directly. </del> <ins> resource directory that cannot be discovered from querying the described device's /.well-known/core resource directly. </ins> It also follows that data in the resource directory can only be <del> 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. </del> <ins> 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. </ins> 3.2.