[core] Links-json: proposal for revision addressing IETF last-call comments

[Carsten Bormann <[e-mail]>]

On Dec 14, 2017, at 16:31, Carsten Bormann <[e-mail]> wrote:
> 
> 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.

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