[core] links-json: target resolution in presence of anchors / RFC8288

[Christian Amsüss <[e-mail]>]

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 <http://internal-host/>:

    </b>;rel="x";anchor="http://external-host/"

If this is sent in an RFC6690 document, it means

    <http://external-host/b>;rel="x";anchor="http://external-host/"

but if it is sent in an RFC8288 header, it means

    <http://internal-host/b>;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
`[{href:"/b",anchor:"http://external-host"}]` is inexpressable in
RFC6690 documents, and `</b>;anchor="http://external-host/"` needs to be
converted to `[{href:"http://external-host/b",...}]` 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]: https://mailarchive.ietf.org/arch/msg/core/6r-Dcl6l4ieqzI4K4p5KkQZ7HcI

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom