Re: [core] Modernized Link Format
Christian Amsüss <christian@amsuess.com> Thu, 11 October 2018 12:47 UTC
Return-Path: <christian@amsuess.com>
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 ABFB3130DD1 for <core@ietfa.amsl.com>; Thu, 11 Oct 2018 05:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TfZmU2uzbtuD for <core@ietfa.amsl.com>; Thu, 11 Oct 2018 05:47:06 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0C3127AC2 for <core@ietf.org>; Thu, 11 Oct 2018 05:47:05 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 022F741AD8; Thu, 11 Oct 2018 14:47:04 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B3A152A; Thu, 11 Oct 2018 14:47:02 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 570AC10E; Thu, 11 Oct 2018 14:47:02 +0200 (CEST)
Received: (nullmailer pid 12294 invoked by uid 1000); Thu, 11 Oct 2018 12:47:01 -0000
Date: Thu, 11 Oct 2018 14:47:01 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Klaus Hartke <hartke@projectcool.de>
Cc: "core@ietf.org WG" <core@ietf.org>
Message-ID: <20181011124700.GB2437@hephaistos.amsuess.com>
References: <CAAzbHvZiSQvpK=qwtaQX2L5QjZ7nerLW_=eBPFmEhg5YrUPqMA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB"
Content-Disposition: inline
In-Reply-To: <CAAzbHvZiSQvpK=qwtaQX2L5QjZ7nerLW_=eBPFmEhg5YrUPqMA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9eY1PsLrZJsJd6m99eXa0uNNFzg>
Subject: Re: [core] Modernized Link Format
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Oct 2018 12:47:09 -0000
Hello Klaus, thanks for comment. On Thu, Oct 11, 2018 at 01:47:30PM +0200, Klaus Hartke wrote: > at <coap://example.com:1234/.well-known/core>... > > <foo/bar> > > ....would resolve to the following URI under the old rules... > > coap://example.com:1234/foo/bar > > ....and to the following URI under the new rules... > > coap://example.com:1234/.well-known/foo/bar > > ....regardless of whether "rel" is the implicit "hosts" relation type > as in this example or any other relation type. > > Is that correct? Yes. (In neither document, an explicit or implicit rel has an impact on the reference resolution.) > While the impact of this change on existing deployments might be low, > it's a breaking change and as such IMO requires an RFC that updates or > obsoletes RFC 6609. The new interpretation is only used when an application explicitly specifies it (as does the RD). Applications "in the wild" are, as it is written now, not affected. The choices we have in RD are, to my understanding, as follows: a) What is in -15: Bend link-format only when used in RD (or any other document that opts in to that -- I figure core-interfaces will) b) Update 6690... b1) ... in a 6690bis b2) ... in Resource Directory c) Use 6690 interpretation in RD We've ruled out c) over the last year b/c it means that features of the RD will not be available (ie. some links can not be expressed in any serialization format) until one can actually use a format that doesn't suffer from 6690's weird resolution rules (ie. CoRAL or 6690bis). Moreover, if we went by c, any deployed RD would keep us from a 6690bis, for an RD implementation needs to resolve URIs. Among b and a, a was picked because hopes were that would allow for the fastest progress of RD which is way behind schedule; also, it allows doing b1 later easily. I'm all for doing any of the b options, but I don't rather not have them delay the RD. What puts me off b1 a bit is that it'll attract fixes to other oddities of 6690 too (eg. clarifying rel=hosts, recommending against whitespace-separated values), delaying RD by a year or more. (And that's not even thinking of the links-json process). Say we wanted to go for b2, as you suggest. Is that possible at all, procedurally? How thorough would an investigation into the current users need to be to allow re-using the content format number and media type? (I have asked around and not seen or heard of a single implementation of RFC6690 that relies on the odd behaviors, but obviously didn't ask all readers of 6690. It appears to me that not even the original authors were fully aware of their rules, or all examples would start with `<x` rather than with `</x` for brevity.) Best regards Christian -- Ceterum censeo RFC6690 esse revidendam. -- me, in mails from April on that topic
- [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Christian Amsüss
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Christian Amsüss
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Christian Amsüss
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Jim Schaad
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Jim Schaad