[core] Links-json: proposal for revision addressing IETF last-call comments
Carsten Bormann <cabo@tzi.org> Sun, 25 February 2018 21:29 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 3DC70120454; Sun, 25 Feb 2018 13:29:51 -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 VCpUMVPM5yQi; Sun, 25 Feb 2018 13:29:48 -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 9F47E120724; Sun, 25 Feb 2018 13:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1PLTfsn028083; Sun, 25 Feb 2018 22:29:41 +0100 (CET)
Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zqJ51005NzDXsy; Sun, 25 Feb 2018 22:29:40 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <FDEED306-BDA9-407E-96D7-6A5C9472FA28@tzi.org>
Date: Sun, 25 Feb 2018 22:29:40 +0100
Cc: draft-ietf-core-links-json@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 541286978.545785-fc18ad8e872123d78d13a3335fbf7089
Content-Transfer-Encoding: quoted-printable
Message-Id: <53E184FA-7370-4B64-BE86-D88ABA10B313@tzi.org>
References: <20171214114204.GA31455@hephaistos> <FDEED306-BDA9-407E-96D7-6A5C9472FA28@tzi.org>
To: Christian Amsüss <c.amsuess@energyharvesting.at>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/BGLNTjKD0S3uZVQsAA6DxtLt0Cc>
Subject: [core] Links-json: proposal for revision addressing IETF last-call comments
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: Sun, 25 Feb 2018 21:29:51 -0000
On Dec 14, 2017, at 16:31, Carsten Bormann <cabo@tzi.org> 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
- [core] links-json: target resolution in presence … Christian Amsüss
- Re: [core] links-json: target resolution in prese… Carsten Bormann
- [core] Links-json: proposal for revision addressi… Carsten Bormann