Re: [core] Modernized Link Format

Christian Amsüss <christian@amsuess.com> Thu, 11 October 2018 13:53 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 65782130E74 for <core@ietfa.amsl.com>; Thu, 11 Oct 2018 06:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 bb7YREXNyJKQ for <core@ietfa.amsl.com>; Thu, 11 Oct 2018 06:53:28 -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 3352F130DD6 for <core@ietf.org>; Thu, 11 Oct 2018 06:53:28 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3B12D41AD8; Thu, 11 Oct 2018 15:53:26 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 783962A; Thu, 11 Oct 2018 15:53:24 +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 CCAC410E; Thu, 11 Oct 2018 15:53:23 +0200 (CEST)
Received: (nullmailer pid 20204 invoked by uid 1000); Thu, 11 Oct 2018 13:53:22 -0000
Date: Thu, 11 Oct 2018 15:53:22 +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: <20181011135318.GD7477@hephaistos.amsuess.com>
References: <CAAzbHvZiSQvpK=qwtaQX2L5QjZ7nerLW_=eBPFmEhg5YrUPqMA@mail.gmail.com> <20181011124700.GB2437@hephaistos.amsuess.com> <CAAzbHvYR+KjFe-_31qnkYt6qcO9jBpGeaF7B1yiw9BK9oRVfkg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6"
Content-Disposition: inline
In-Reply-To: <CAAzbHvYR+KjFe-_31qnkYt6qcO9jBpGeaF7B1yiw9BK9oRVfkg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/-xqggpoOE_T_80evfLbUVBivVx0>
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 13:53:32 -0000

On Thu, Oct 11, 2018 at 03:28:34PM +0200, Klaus Hartke wrote:
> Just to clarify: You can always, write link targets as "URI" or
> "path-absolute" [RFC3986], right? (That's not very efficient but not
> not expressible.)

Yes, *provided* you can construct the URI the requester had in mind when
accessing your system (the client might not have sent your host name
along).

Later changes in the base address are not possible (precise: not
meaningful) when all links were fully expanded. The protocol-negotiation
mechanisms not fully usable with fully expressed URIs either, as I
understand them.

> Thinking about it a bit more, I only see two ways forward: Keep the
> "application/link-format" media type and add a version indicator to
> the representation format that prevents legacy applications from
> applying the wrong semantics.

That avoids the formal mess, but creates a practical one. Code is out
there that produces documents in "link-format;version=any" (documents
that work with both 6690 and modernized). Moving everything over to
link-format;version=2 at ct=39 creates formal clarity and practical
non-interoperability for them.

If there is but one righteous citizen of 6690, let them have the code
point. My impression is there is none.

> Or use an entirely different media type
> (e.g., "application/link-format+cbor" with fixed rules,
> "application/coral+cbor").

I've asked the authors of link-format+{json,cbor} to do right that in
[1], but the version that's about to be released contains no
clarification to that matter AFAIK.

CoRAL -- yes, that's why I asked about whether we can have a preview
release of CoRAL without the research-ish forms parts in it. If CoRAL
were a document heading towards WGLC, I'd be happy to recommend CoRAL
for RD use on all sides, and state that link-format can be used per
RFC6690 but is limited as outlined in an appendix, and power users
should use CoRAL or better.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/eNSR6jnP-gvZZ_zHkb097sFQyog

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