Original text:
"coap://sensor1.example.com" and "coap://sensor2.example.com", and posted the very payload of the 6th request of section 5 of RFC6690. <del> Note that said content is in violation of the rule against relative references in presence of the anchor attribute; the server accepted it because no ambiguity is created in this particular case. </del> It demonstrates how absolute link targets stay unmodified, while relative ones are resolved:

Reviewer comments:
Closes: URL See rationale there. Action if not commented on: merge
The proposal from last meeting about handling RC66900-vs-8288 needs to be implemented: Prescribe that the RD always send href in absolute form if anchor is present (things like can stay relative) Adapt all examples Update the illustrative appendix Describe motivation for the rule
Open questions: Will links-json follow what we discussed and have clear 8288-style resolution? (waiting for responses to ) Shall the rule for permissible data at registration be "no relative href when anchor is present" (clear and concise, but overly restrictive at or "no relative href when anchor is present and more absolute than the target" (verbose to describe, but less restrictive / doesn't produce collateral damage)? The current proposal acknowledges the problem when referring to "the payload of the 6th request of section 5 of..."; the appendix will also need to have its examples adapted further on that when it's decided.
The sharper variety of the rules can be phrased like this: (For RFC6690 documents), "If anchor is an absolute reference, the target reference must be absolute. If the anchor is a relative reference, the target can only be a relative reference if its takes the same ABNF alternative choice as the anchor's , or a choice listed earlier in the ABNF definition of in RFC 3986 -- unless anchor is of the form, in which case the target can not take the too but must be absolute or pick an earlier choice. (Figuratively speaking, the anchor can not be more absolute than the target)." Quite a mouthful just to keep allowing all examples of RFC6690 like in .. (The "bad" cases that cause ambiguity never showed up in any examples so far unless they were constructed on purpose to show the ambiguity.) I've pushed a version that includes the more restrictive variety to master to keep things flowing.
Revisiting this: fine-graned wording seems to be overkill, but so is ruling out common expressions in .well-known/core documents. Toning down to "SHOULD NOT contain statements that would cause ambiguity between RFC6690 and RFC8288 interpretation" in an upcoming pull request to close this issue. Hello links-json authors, there is a discrepancy between the Link Format described in RFC6690 and the Link header described in RFC8288 (formerly 5988bis). Take the example this line obtained from a resource : ;rel="x";anchor="http://external-host/" If this is sent in an RFC6690 document, it means ;rel="x";anchor="http://external-host/" but if it is sent in an RFC8288 header, it means ;rel="x";anchor="http://external-host/" On the formal side, this means that some statements can not be expressed in RFC6690 link format without knowledge of where the resource is served from. This is detrimental when describing links in an (esp. statically configured) collection to describe members using outside anchors. On the practical side, this leads to implementations doing the resolution wrong because none of the documents points out that there is a difference. On the social side, this results in many questions about link resolutions, and us CoRE people teaching ways that are not applicable to the rest of the web linking world. This point is especially relevant to links-json given it aims to be usable in the regular web world too. Please include a statement as to which of the interpretations is applied to JSON and CBOR link format documents. I strongly recommend to take up the interpretation of RFC8288. This does have effects on roundtrip-ability (the meaning of is inexpressable in RFC6690 documents, and needs to be converted to but retains the same semantics), but I still think that it is better to have that complexity in the converters than to carry on the mistakes[1] of the past into the next generation of content formats. Having a decision is also relevant to the Resource Directory draft (where this discussion comes from) because we need to either stay that we have to impose the same restrictions on JSON/CBOR documents as we do on RFC6690 ones ("no relative hrefs when anchor is present"), or we can recommend using JSON/CBOR link format because it can be used without worries. Best regards Christian [2]: My personal opinion of the origin of the discrepancy is that it was an honest mistake in reading 5988 back when 6690 was written (otherwise it would have been pointed out as a deliberate decision to deviate here) -- I made the same mistake myself[2] revisiting 5988. The newer 8288 does not allow for that interpretation any more. [1]: URL To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

Revised text:
"coap://sensor1.example.com" and "coap://sensor2.example.com", and posted the very payload of the 6th request of section 5 of RFC6690.  It demonstrates how absolute link targets stay unmodified, while relative ones are resolved: