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 =?iso-8859-1?Q?Ams=FCss?= <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