Original text:
information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove <del> information on resources.  Furthermore, new link attributes useful in conjunction with an RD are defined. </del>  1. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, <del> new link attributes useful in conjunction with a Resource Directory </del>  are defined.  Although the examples in this document show the use of these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. the network (see mc-registration. A Resource Directory MAY provide hints about the content-formats it <del> supports in the links it exposes or registers, using the "ct" link </del>  attribute, as shown in the example below.  Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. the human readable name of the parameter, <del> the short name as used in query parameters or link attributes, </del>  indication of whether it can be passed as a query parameter at registration of endpoints, as a query parameter in lookups, or be <del> expressed as a link attribute, </del>  validity requirements if any, and Initial entries in this sub-registry are as follows: <del> (Short: Short name used in query parameters or link attributes.  Use: R = used at registration, L = used at lookup, A = expressed in link attribute </del>  The descriptions for the options defined in this document are only summarized here.  To which registrations they apply and when they are described property actually a property of the endpoint and not a property of a particular resource, in which case it should go into the payload of the registration and need not be registered?), and the <del> potential for conflict with commonly used link attributes (For </del>  example, "if" could be used as a parameter for conditional registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 link attribute).  It is expected </del>  that the registry will receive between 5 and 50 registrations in total over the next years.

Reviewer comments:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.

Revised text:
information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove  <ins> information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined. </ins> 1. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore,  <ins> new target attributes useful in conjunction with a Resource Directory </ins> are defined.  Although the examples in this document show the use of these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. the network (see mc-registration. A Resource Directory MAY provide hints about the content-formats it  <ins> supports in the links it exposes or registers, using the "ct" target </ins> attribute, as shown in the example below.  Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. the human readable name of the parameter,  <ins> the short name as used in query parameters or target attributes, </ins> indication of whether it can be passed as a query parameter at registration of endpoints, as a query parameter in lookups, or be  <ins> expressed as a target attribute, </ins> validity requirements if any, and Initial entries in this sub-registry are as follows:  <ins> (Short: Short name used in query parameters or target attributes. Use: R = used at registration, L = used at lookup, A = expressed in target attribute </ins> The descriptions for the options defined in this document are only summarized here.  To which registrations they apply and when they are described property actually a property of the endpoint and not a property of a particular resource, in which case it should go into the payload of the registration and need not be registered?), and the  <ins> potential for conflict with commonly used target attributes (For </ins> example, "if" could be used as a parameter for conditional registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered  <ins> endpoint property or the RFC6690 target attribute).  It is expected </ins> that the registry will receive between 5 and 50 registrations in total over the next years.