Re: [core] Link target attributes in CoRAL (was: Review of CoRAL)

Christian M. Amsüss <christian@amsuess.com> Tue, 06 November 2018 08:41 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 E1EA1128A6E for <core@ietfa.amsl.com>; Tue, 6 Nov 2018 00:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level:
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no 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 moRTQTtLMrN2 for <core@ietfa.amsl.com>; Tue, 6 Nov 2018 00:41:38 -0800 (PST)
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 C2B701277C8 for <core@ietf.org>; Tue, 6 Nov 2018 00:41:37 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D5A3C41EAF; Tue, 6 Nov 2018 09:41:35 +0100 (CET)
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 DC3086E; Tue, 6 Nov 2018 09:41:34 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9859837; Tue, 6 Nov 2018 09:41:34 +0100 (CET)
Received: (nullmailer pid 20468 invoked by uid 1000); Tue, 06 Nov 2018 08:41:34 -0000
Date: Tue, 6 Nov 2018 09:41:34 +0100
From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= <christian@amsuess.com>
To: Klaus Hartke <hartke@projectcool.de>
Cc: "core@ietf.org WG" <core@ietf.org>
Message-ID: <20181106084134.GC4293@hephaistos.amsuess.com>
References: <CAAzbHvYk9dUvGmYsX1U=0qcU7330bYO6YjGAa51gFKMGGoy-Dg@mail.gmail.com> <20181105123604.GA9680@hephaistos.amsuess.com> <CAAzbHvZ=4GaPH6FXj4ZuOzMLrQbWUo-Oc6CUmiA4O2b3PhK-rA@mail.gmail.com> <CAAzbHvaSDzc62-dY-ALQxW6bGKS7avCv795-DUMh0PVRF+yaqw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl"
Content-Disposition: inline
In-Reply-To: <CAAzbHvaSDzc62-dY-ALQxW6bGKS7avCv795-DUMh0PVRF+yaqw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/QkE3rr0EGPzoXUEz5Sj68NCVyds>
Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL)
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: Tue, 06 Nov 2018 08:41:40 -0000

On Tue, Nov 06, 2018 at 09:21:36AM +0100, Klaus Hartke wrote:
> Christian Amsüss wrote:
> > I don't think we need a guarantee for that. We can, as they pop up, for
> > some funny-string-valued attributes define equivalent more semantic
> > attributes, each with their own mapping. So a general CoRAL processor
> > you could encounter both `attr: rt="x y"` or `split-attr:rt rt:x,
> > split-attr rt:y` and needs to know of the equivalence.
>
> This is exactly what I'd like to avoid.
>
> [later]
> 
> Of course, we could for new link target attributes, as they pop up,
> define an equivalent more semantic link relation type. In Link Format
> you would use the link target attribute; in CoRAL, the link relation
> type. If a converter encounters a new, unknown attribute, it would fail.

Only defining the mapping for known target attributes would neatly get
us rid of the issue of link attributes. Implementations could still be
as simple as possible (ie. not even have an enumeration of known
attributes) if they accept producing odd output on unspecified input,
and follow the most common rule (map to attr:${key} "${value}") on all
but the known whitespacers.

My expectation though is that processors that convert link-format to
CoRAL would be less constrained devices (C2 or larger), and that smaller
devices that still want to serve both would have something equivalent to
hard-copies of both representation in ROM instead -- is that a
reasonable one?

Best regards
Christian

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