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

[Christian Amsüss]

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

[Carsten Bormann]

Hi Christian,

(Speaking as a core-links-json co-author:)

We indeed have experienced a shift of focus here.

When the work on links-json started, seamless roundtripping with RFC 6690 link-format was the foremost objective.

But, in the meantime, seamless integration into the larger Web world (both Big Web and Thing Web) was become of foremost importance.

Three aspects of RFC 6690 are in the way here:
— it is based on RFC 5988, which has been superseded by RFC 8288, with many problems solved — in particular the handling of starred attributes (such as title*) can be much simplified now.
— it uses a rather simplified form of resolving percent encoding, which works great for limited use cases, but prevents its seamless use with Web applications that may employ more complex percent encoding.
— it has unusual rules for resolving relative links, which is the point that you are referring to.

We can work around the third problem by only using absolute links, which will be the fix for RD for now.

The deviation of RFC 6690 from the relative link handling that would be usual for RFC 8288 (and, actually, also for RFC 5988 already) was a feeble attempt to get some URI compression into the format (relative URIs can be shorter than absolute ones). This kind of works, for certain use cases, but is brittle. A better way is to go back to absolute links and address the URI compression objective separately, maybe even in a different RFC. This does need some thinking. (I may be worth to remember that RDF has been using a form URI compression from the outset, and we may want to learn from there — see also link-employing formats such as CORAL!)

So the next step is to integrate these learnings into links-json and come up with a new version.
This will obviously need another WGLC before we hand it back to the IESG.
By addressing this heads-on, the process should also fix the blocking issues that got it stuck in the IESG, so we should be able to finish this soon.

Grüße, Carsten

[Carsten Bormann]

Post by Carsten Bormann
Hi Christian,
(Speaking as a core-links-json co-author:)
We indeed have experienced a shift of focus here.
When the work on links-json started, seamless roundtripping with RFC 6690 link-format was the foremost objective.
But, in the meantime, seamless integration into the larger Web world (both Big Web and Thing Web) was become of foremost importance.
— it is based on RFC 5988, which has been superseded by RFC 8288, with many problems solved — in particular the handling of starred attributes (such as title*) can be much simplified now.
— it uses a rather simplified form of resolving percent encoding, which works great for limited use cases, but prevents its seamless use with Web applications that may employ more complex percent encoding.
— it has unusual rules for resolving relative links, which is the point that you are referring to.
We can work around the third problem by only using absolute links, which will be the fix for RD for now.
The deviation of RFC 6690 from the relative link handling that would be usual for RFC 8288 (and, actually, also for RFC 5988 already) was a feeble attempt to get some URI compression into the format (relative URIs can be shorter than absolute ones). This kind of works, for certain use cases, but is brittle. A better way is to go back to absolute links and address the URI compression objective separately, maybe even in a different RFC. This does need some thinking. (I may be worth to remember that RDF has been using a form URI compression from the outset, and we may want to learn from there — see also link-employing formats such as CORAL!)
So the next step is to integrate these learnings into links-json and come up with a new version.
This will obviously need another WGLC before we hand it back to the IESG.
By addressing this heads-on, the process should also fix the blocking issues that got it stuck in the IESG, so we should be able to finish this soon.

Based on these considerations, I have generated a draft draft-ietf-core-link-json-10 that I plan to submit tomorrow for wider review.

This is rebased on RFC 8288 (which supersedes RFC 5988), uses IRIs to navigate around at least some of the percent-encoding issues we identified, and adds language-tagged values.

Comments are welcome!

The draft draft is still in the WG SVN (yes, it is *that* old):
https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-links-json-xx.txt

Diff from previously submitted I-D:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-links-json-09.txt&url2=https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-links-json-xx.txt
or
https://goo.gl/VPfUDX
for short.

Grüße, Carsten