Re: [core] Review of CoRAL

Christian Amsüss <> Thu, 08 November 2018 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C7B112872C; Thu, 8 Nov 2018 06:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cLC42rOq4JT4; Thu, 8 Nov 2018 06:45:52 -0800 (PST)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB4B3126CB6; Thu, 8 Nov 2018 06:45:51 -0800 (PST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id DCDBB41F32; Thu, 8 Nov 2018 15:45:49 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id C54A86B; Thu, 8 Nov 2018 15:45:48 +0100 (CET)
Received: from ( [IPv6:2a02:b18:c13b:8010::71b]) by (Postfix) with ESMTPSA id 6F6572E; Thu, 8 Nov 2018 15:45:48 +0100 (CET)
Received: (nullmailer pid 20479 invoked by uid 1000); Thu, 08 Nov 2018 14:45:48 -0000
Date: Thu, 8 Nov 2018 15:45:48 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [core] Review of CoRAL
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Nov 2018 14:45:55 -0000

Hi Klaus,

some more points came up pushing forward my implementation:

* On "Why are there bare-words as relation strings": During
  refactoring[1], I found why I had that -- the append-rel path type
  seemed to indicate that the rel should be something usable here.

  Now the code in the draft is a bit vague here (`format(relation,
  "x")`), and there's no text on it yet. Any ideas yet on how I'd come
  from a URI to an appendable string (like uri_to_rel(x) = rightmost
  substring of x where x in [a-zA-Z.0-9-])? Will it be sufficent on a
  constrained device that has hardcoded knowledge of what the URIs mean
  to only store uri_to_rel(rel_number_to_uri(n)) for all n in the
  supported profiles?

* current base IRI: Current base IRI keeps being updated to
  current context IRIs. That is a good idea in terms of compact
  representations, but means that local references can not be expressed
  "deep in there".

  Say I want to say that "</temp> is described by
  <>, where
  <> has author <mailto:..>, change
  log at <...> *and is also available at </descr>*" (like a local cached
  version).  By the time I talk about the thing at, my
  context and current base URI is, and I can't
  say </descr> any more meaning a local resource.

  (Note that this is a bit of a similar situation as with RFC6690, but
  sans all the confusion.)

  In this very example, one could work around by saying that "is also
  available at" is symmetric, so one could instead say "Furthermore,
  </descr> is also available at <>",
  which would be another toplevel link, but it means that a *generic*
  link-format document can not necessarily be expressed easily.

  I have no concrete proposal of how this could be done better. One idea
  is to allow expressing "rev" and not only "rel", but have not thought
  through whether this solves the issue completely at all.

Best regards, and sorry for the somewhat chaotic way in which my
observations and questions arrive

[1] which has led to micrurus to be what I believe to be correct again,
not only w/rt flat CIRIs, but also with base URI changes and
delta-compressed relation numbers

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