Original text:
The expression "a URI-reference is _resolved against_ a base URI" is used to describe the process of RFC3986 Section 5.2. <del> Noteworthy corner cases are that resolving an absolute URI against any base URI gives the original URI, and that resolving an empty URI reference gives the base URI. </del>  A web entity that stores information about web resources and scheme and authority information about an Endpoint.  The Registration Base URI is provided by the Endpoint at registration time, and is used by the Resource Directory to resolve relative <del> references inside the registration into absolute URIs. </del>  The target of a link is the destination address (URI) of the link. While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD <del> therefore accept URIs of all schemes they support, both in absolute and relative forms, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </del>  The URI Discovery operation can yield multiple URIs of a given resource type.  The client can use any of the discovered addresses A relative href value denotes the path to the registration resource of the Endpoint.  When pointing to a registration resource on a <del> different RD, the href value is an absolute URI. </del>  6.2. Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) base URI of the registration <del> as the anchor.  Links whose href or anchor was submitted as an absolute URI are returned with respective attributes unmodified. </del>  Above rules allow the client to interpret the response as links without any further knowledge of what the RD does.  The Resource match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any group resource that endpoint is contained in.  Queries for resource <del> link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </del>  Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource 13.  changes from -13 to -14 Rename "registration context" to "registration base URI" (and

Reviewer comments:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.

Revised text:
The expression "a URI-reference is _resolved against_ a base URI" is used to describe the process of RFC3986 Section 5.2.  <ins> Noteworthy corner cases are that if the URI-reference is a (full) URI and resolved against any base URI, that gives the original full URI, and that resolving an empty URI reference gives the base URI without any fragment identifier. </ins> A web entity that stores information about web resources and scheme and authority information about an Endpoint.  The Registration Base URI is provided by the Endpoint at registration time, and is used by the Resource Directory to resolve relative  <ins> references inside the registration into URIs. </ins> The target of a link is the destination address (URI) of the link. While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD  <ins> therefore accept URIs of all schemes they support, both as URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </ins> The URI Discovery operation can yield multiple URIs of a given resource type.  The client can use any of the discovered addresses A relative href value denotes the path to the registration resource of the Endpoint.  When pointing to a registration resource on a  <ins> different RD, the href value is a URI. </ins> 6.2. Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) base URI of the registration  <ins> as the anchor.  Links whose href or anchor was submitted as a (full) URI are returned with respective attributes unmodified. </ins> Above rules allow the client to interpret the response as links without any further knowledge of what the RD does.  The Resource match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any group resource that endpoint is contained in.  Queries for resource  <ins> link targets MUST be in URI form (ie. not relative references) and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource 13. <ins> changes from -14 to -15 Talk of "relative references" and "URIs" rather than "relative" and "absolute" URIs.  (The concept of "absolute URIs" of RFC3986 is not needed in RD). </ins> changes from -13 to -14 Rename "registration context" to "registration base URI" (and