Draft: draft-ietf-core-resource-directory

Commentary: Even disregarding the examples that necessarily have the slash , this ( vs. plain .well - known / core ) version was the more common in the text so far . Closes : < /del < ins</ins 
 This actually 
 Current master branch text is really unclear : What does it mean : " used to find the identification " ? Can we say intead " used to identify the components " ? How can the URI discovery process identify client - server incompatibilities ? CoAP does n't let you discover supported protocol versions , options , etc . as far as I know , by default . For those implementations not supporting I - D.bormann - t2trg - rel - impl , it is really unclear what to do with this paragraph . 
 Oups , wrong link in the commit -- sorry for the noise 
 The intention behind this paragraph is merely to point those who want versioning and more RD metadata that is immaterial to the regular operation to a place where they can safely do so . I see , however , how the " it is necessary to " makes this sound like more than there really is to it . Accordingly , the incompatibilities part is not about finding that something ca n't work in the first place ( that works on a positive - list base using rt and that like ) , but more for understanding later why things do n't work ( say , client X produces a document that upsets RD implementation Y in versions earlier than 0.4.1 ) . The address is in section 4 of 6690 ( ie . just .well - known / core ) ; now referred to by the name it has there . 
 A couple of places has " .well - known / core " as resource name , while in most places it says " /.well - known / core " . Proposal is to update all occurrences to the latter form . ( Maybe this is already addressed in the pull requests with nits , but there are so many - hard to check ... )
Paragraph (version A):
The web server is free to choose links it deems appropriate to be
exposed in its ".well-known/core".  Typically, the links describe
resources that are served by the host, but the set can also contain
links to resources on other servers (see examples in RFC6690 page
14).  The set does not necessarily contain links to all resources
served by the host.
Paragraph (version B):
The web server is free to choose links it deems appropriate to be
exposed in its "/.well-known/core".  Typically, the links describe
resources that are served by the host, but the set can also contain
links to resources on other servers (see examples in RFC6690 page
14).  The set does not necessarily contain links to all resources
served by the host.
Paragraph (version A):
When registrants publish information in the RD that is not available
to any client that would query the registrant's .well-known/core
interface, or when lookups to that interface are subject so stricter
firewalling than lookups to the RD, the RD may need to limit which
lookup clients may access the information.
Paragraph (version B):
When registrants publish information in the RD that is not available
to any client that would query the registrant's /.well-known/core
interface, or when lookups to that interface are subject so stricter
firewalling than lookups to the RD, the RD may need to limit which
lookup clients may access the information.
Paragraph (version A):
Simple registration could be used to circumvent address-based access
control: An attacker would send a simple registration request with
the victim's address as source address, and later look up the
victim's .well-known/core content in the RD.  Mitigation for this is
recommended in simple.
Paragraph (version B):
Simple registration could be used to circumvent address-based access
control: An attacker would send a simple registration request with
the victim's address as source address, and later look up the
victim's /.well-known/core content in the RD.  Mitigation for this is
recommended in simple.