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

Carsten Bormann <cabo@tzi.org> Thu, 14 December 2017 15:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CC3126DED; Thu, 14 Dec 2017 07:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7wkd6QWkpkf; Thu, 14 Dec 2017 07:31:10 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA00124319; Thu, 14 Dec 2017 07:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vBEFV3Mo023599; Thu, 14 Dec 2017 16:31:03 +0100 (CET)
Received: from [192.168.217.114] (p5DC7F151.dip0.t-ipconnect.de [93.199.241.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yyHZv3JKbzDXhv; Thu, 14 Dec 2017 16:31:03 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20171214114204.GA31455@hephaistos>
Date: Thu, 14 Dec 2017 16:31:01 +0100
Cc: draft-ietf-core-links-json@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 534958260.914469-3bd32420c321aa5369462444b09e1ad0
Content-Transfer-Encoding: quoted-printable
Message-Id: <FDEED306-BDA9-407E-96D7-6A5C9472FA28@tzi.org>
References: <20171214114204.GA31455@hephaistos>
To: Christian Amsüss <c.amsuess@energyharvesting.at>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/eNSR6jnP-gvZZ_zHkb097sFQyog>
Subject: Re: [core] links-json: target resolution in presence of anchors / RFC8288
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 15:31:12 -0000

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