Draft: draft-ietf-core-resource-directory

Commentary: 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 : 
 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  , 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 .
Paragraph (version A):
information on resources.  Furthermore, new link attributes useful in
conjunction with an RD are defined.
Paragraph (version B):
information on resources.  Furthermore, new target attributes useful
in conjunction with an RD are defined.
Paragraph (version A):
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,
new link attributes useful in conjunction with a Resource Directory
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.
Paragraph (version B):
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,
new target attributes useful in conjunction with a Resource Directory
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.
Paragraph (version A):
A Resource Directory MAY provide hints about the content-formats it
supports in the links it exposes or registers, using the "ct" link
attribute, as shown in the example below.  Clients MAY use these
hints to select alternate content-formats for interaction with the
Resource Directory.
Paragraph (version B):
A Resource Directory MAY provide hints about the content-formats it
supports in the links it exposes or registers, using the "ct" target
attribute, as shown in the example below.  Clients MAY use these
hints to select alternate content-formats for interaction with the
Resource Directory.
Paragraph (version A):
the short name as used in query parameters or link attributes,
Paragraph (version A):
indication of whether it can be passed as a query parameter at
registration of endpoints, as a query parameter in lookups, or be
expressed as a link attribute,
Paragraph (version B):
the short name as used in query parameters or target attributes,
Paragraph (version B):
indication of whether it can be passed as a query parameter at
registration of endpoints, as a query parameter in lookups, or be
expressed as a target attribute,
Paragraph (version A):
The IANA policy for future additions to the sub-registry is "Expert
Review" as described in RFC8126.  The evaluation should consider
formal criteria, duplication of functionality (Is the new entry
redundant with an existing one?), topical suitability (E.g. is the
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
potential for conflict with commonly used link attributes (For
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
endpoint property or the RFC6690 link attribute).  It is expected
that the registry will receive between 5 and 50 registrations in
total over the next years.
Paragraph (version B):
The IANA policy for future additions to the sub-registry is "Expert
Review" as described in RFC8126.  The evaluation should consider
formal criteria, duplication of functionality (Is the new entry
redundant with an existing one?), topical suitability (E.g. is the
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
potential for conflict with commonly used target attributes (For
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
endpoint property or the RFC6690 target attribute).  It is expected
that the registry will receive between 5 and 50 registrations in
total over the next years.