Change:
This responds to a comment from Jim on the use of the term "Origin" in RFC6690 which I had previously missed. Given that the old 6690-style documents are thus a lot less powerful, the text goes from "Submitted documents should be the same in both interpretations, and the RD can use either" to "Submitted documents should be the same, and the RD interprets them 8288 style". A paragraph was added that defines precisely what it means to interpret it 8288 style. Several outdated references to where resolution happens have been removed. The "8288 style interpretation" is called Modernized Link Format; I'd be happy of any better names, but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again.

Discussion:
_who_ "hosts" something. In link-format serialization, it is expressed in the "anchor" <del> attribute.  There, it can be a relative reference, in which case it gets resolved against the URI of the ".well-known/core" document it was obtained from.  It defaults to that document's URI. </del> <ins> attribute.  It defaults to that document's URI. </ins> A link target URI: It defines the destination of the relation (eg. _what_ is hosted), and is the topic of all target attributes.

In link-format serialization, it is expressed between angular brackets, and sometimes called the "href". <del> If there is an anchor attribute present and the link is serialized in RFC6690 link format, this document will require that the link is an absolute reference to avoid the ambiguities outlined in resolution- rules. Otherwise, it can be serialized as a relative URI, and gets resolved against the document's URI. </del> Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information about the target URI.

parameter or constructed implicitly from the requester's network address. <del> Documents in RFC6690 Link Format SHOULD NOT contain links in which resolving the target literal against the base URI gives a different result than resolving it against the resolved anchor; this is to avoid the ambiguities described in resolution-rules. Entries in which there is no anchor attribute, entries in which the target is an absolute reference and entries in which both the target and the anchor start with a slash ("/") </del> <ins> Link format documents submitted to the resource directory are interpreted as Modernized Link Format (see modern6690) by the RD.  A registree-ep SHOULD NOT submit documents those interpretation according to RFC6690 and modern6690 differs and RFC6690 interpretation is intended to avoid the ambiguities described in resolution-rules. </ins> <del> never cause that kind of ambiguity. </del> <ins> In practice, most links (precisely listed in modern-safe) can be submitted without consideration for those details. </ins> The registration request interface is specified as follows:

persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests.  Endpoints that register with a <del> con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links </del> <ins> con that contains a path component can not meaningfully use RFC6690 Link Format due to its prevalence of the Origin concept in relative reference resolution; they can submit payloads for interpretation as Modernized Link Format.  Typically, links </ins> submitted by such an endpoint are of the "path-noscheme" (starts with a a path not preceded by a slash, precisely defined in RFC3986 Section 3.3) form.