Re: [core] Modernized Link Format

Christian Amsüss <christian@amsuess.com> Wed, 17 October 2018 16:04 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 D3C79130E08 for <core@ietfa.amsl.com>; Wed, 17 Oct 2018 09:04:14 -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 mtxk8zsnj_wq for <core@ietfa.amsl.com>; Wed, 17 Oct 2018 09:04:11 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0DA130E0F for <core@ietf.org>; Wed, 17 Oct 2018 09:04:11 -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 27CD941B7B; Wed, 17 Oct 2018 18:04:09 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DBE1A2A; Wed, 17 Oct 2018 18:04:06 +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 EEDC243; Wed, 17 Oct 2018 18:04:05 +0200 (CEST)
Received: (nullmailer pid 23057 invoked by uid 1000); Wed, 17 Oct 2018 16:04:04 -0000
Date: Wed, 17 Oct 2018 18:04:04 +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: <20181017160402.GB4084@hephaistos.amsuess.com>
References: <CAAzbHvZiSQvpK=qwtaQX2L5QjZ7nerLW_=eBPFmEhg5YrUPqMA@mail.gmail.com> <20181011124700.GB2437@hephaistos.amsuess.com> <CAAzbHvYR+KjFe-_31qnkYt6qcO9jBpGeaF7B1yiw9BK9oRVfkg@mail.gmail.com> <20181011135318.GD7477@hephaistos.amsuess.com> <CAAzbHvY225KvEPu1P9JwSvHeTOG20BPrEgQoYdY9vzsiDKAU-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+g7M9IMkV8truYOl"
Content-Disposition: inline
In-Reply-To: <CAAzbHvY225KvEPu1P9JwSvHeTOG20BPrEgQoYdY9vzsiDKAU-A@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FJFFo8VgRqBIwwzfZkn6jRsaeCg>
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: Wed, 17 Oct 2018 16:04:15 -0000

On Fri, Oct 12, 2018 at 10:47:20AM +0200, Klaus Hartke wrote:
>    \v2, <foo/bar>
> 
> would resolve to <coap://example.com:1234/.well-known/foo/bar>.

I'm not a bug fan of such in-line version negotiation, and faintly
remember a sentiment from somewhere within the WG that exactly those
things should be covered by content types.

If that's fine with everybody, it'll be with me too, but I more see this
as an incentive to...

> Let's accelerate CoRAL then.

...do this.

The last state I know are our discussions from March, since which
representations (formerly fat links) have been re-introduced.

Has CoRAL received any reviews since then? Is it progressing towards
adoption by T2TRG?

Would we need to / should we, if the RD were to forego fixing RFC6690
and rely on CoRAL to express what can't be said with link-format, do in
terms of implementation limits and profiles? Should there be a dedicated
profile for "CoRAL used as link-format replacement", or would you expect
the default profile to work here? Are there yet examples of a
.well-known/core file expressed in CoRAL?

I'm all for the approach, but at what time frame can it be realized, and
which working groups will need to be involved at which stage to avoid
surprises at IESG review? (Eg. equating target attributes with literal
properties under http://TBD/ is something that could need feedback from
RFC8288's WG^Wauthors^H or other RDF-using WGs.)

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom