Re: [core] Modernized Link Format

Klaus Hartke <> Sun, 21 October 2018 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2888B13103C for <>; Sun, 21 Oct 2018 09:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TzvG1_F7oOpp for <>; Sun, 21 Oct 2018 09:05:00 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46E6813103B for <>; Sun, 21 Oct 2018 09:04:55 -0700 (PDT)
Received: from ([]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gEGDl-0002Ec-KK; Sun, 21 Oct 2018 18:04:53 +0200
Received: by with SMTP id o17-v6so43704858qtr.1 for <>; Sun, 21 Oct 2018 09:04:53 -0700 (PDT)
X-Gm-Message-State: ABuFfoiSxeHNQ64XYSTVoxWASeVDNkG0dEh8Y/EFSENYPdxDvHD8qGL2 ZdmSE1nsy2jNlprmOWhCkiCi3flQhEZkctx4beA=
X-Google-Smtp-Source: AJdET5c6h9l18WWmR07d0xZ8I2GGFXQ18HYJPhDnzd5Ls/Bt1N/krLL5QO2C1SoeAdHyWYY8ppYrpKWy1cCv+A+2+Pw=
X-Received: by 2002:aed:35cb:: with SMTP id d11-v6mr4220098qte.212.1540137892525; Sun, 21 Oct 2018 09:04:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Klaus Hartke <>
Date: Sun, 21 Oct 2018 18:04:20 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= <>
Cc: " WG" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key:;; 1540137896; a856b423;
Archived-At: <>
Subject: Re: [core] Modernized Link Format
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: Sun, 21 Oct 2018 16:05:04 -0000

Christian Amsüss wrote:
> 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?

Adoption is now on the agenda of the T2TRG summary meeting in Bangkok
[1]. The draft hasn't seen any significant reviews since March,

> 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?

While the default profile technically works, it's not as efficient as
it can get since it doesn't assign numeric identifiers, e.g., to the
"hosts" relation type and RFC 6690 link attributes. So there should be
a profile that does for "Link Format in CoRAL" what
draft-ietf-core-links-json-10#section-2.3 [2] does for "Link Format in
CBOR". I don't know if that has to be a profile that is dedicated to
this application or if it'd make sense, for example, to have a general
"CoRE Profile" that works also for /.well-known/core and other CoRE WG

> Are there yet examples of a
> .well-known/core file expressed in CoRAL?

Here's one example from RFC 6690 [3] expressed in CoRAL:


</sensors>;ct=40;title="Sensor Index",


#using <>
#using lf = <http://TBD/>

hosts </sensors> {
    lf:ct "40"

hosts </sensors/temp> {
    lf:rt "temperature-c"
    lf:if "sensor"
    describedby <>
    alternate </t>

hosts </sensors/light> {
    lf:rt "light-lux"
    lf:if "sensor"

> I'm all for the approach, but at what time frame can it be realized, and

I think it'd make sense to have at least one or two interop events, so
it depends on how quickly the draft gets adopted, implementations
created, interoperability confirmed, reviews done.

While I think the draft is already in quite a good state, I would
probably rather lean towards getting it right than rushing it out.

> 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.)

RFC 8288 gives some license to deviate from the spec where it makes
sense in different link serialization formats. For example,  Atom
allows IANA-registered link relation types to be serialized as URIs
using the prefix "", which is
specific to Atom (and adopted by CoRAL) and not part of RFC 8288 [4].
So I don't think there's a hard dependency on feedback from the RFC
8288 authors. Review from the RFC 8288 authors and other working
groups would be welcome, of course.

One thing that could raise eyebrows is if the CoRE WG started to
assign numeric identifiers to all IANA-registered link relation types
[5]. I thought of doing that in draft-hartke-core-apps-07 [6], but am
now not so sure if that is the right path.

Does anything else come to your mind that could lead to surprises at
IESG review?