Re: [core] Modernized Link Format

Jim Schaad <ietf@augustcellars.com> Sun, 21 October 2018 16:33 UTC

Return-Path: <ietf@augustcellars.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 34C0012D7EA for <core@ietfa.amsl.com>; Sun, 21 Oct 2018 09:33:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 xWEb_I0GHkKh for <core@ietfa.amsl.com>; Sun, 21 Oct 2018 09:33:22 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B0D129BBF for <core@ietf.org>; Sun, 21 Oct 2018 09:33:21 -0700 (PDT)
Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 21 Oct 2018 09:27:54 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Klaus Hartke' <hartke@projectcool.de>, "'Christian M. Amsüss'" <christian@amsuess.com>
CC: core@ietf.org
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> <20181017160402.GB4084@hephaistos.amsuess.com> <CAAzbHvbG2MxMmYPjqxFiHQqs8Y4mE-_rWuc0cgsKnGgeZKdwQA@mail.gmail.com>
In-Reply-To: <CAAzbHvbG2MxMmYPjqxFiHQqs8Y4mE-_rWuc0cgsKnGgeZKdwQA@mail.gmail.com>
Date: Sun, 21 Oct 2018 09:32:31 -0700
Message-ID: <01c301d4695b$abc87ad0$03597070$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKuQjWRwUSBcK32eG9k212nxyowzQEJQX3nA2IoELkCb3v7JgGYgrTNAko7gBAB34LvRKMRSZzQ
Content-Language: en-us
X-Originating-IP: [192.168.1.162]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lGd3NItgJhDAh1F1gmW4h1bMYvo>
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: Sun, 21 Oct 2018 16:33:24 -0000

Would it be possible to get a link to CoRAL as I don't think I have ever seen it.

> -----Original Message-----
> From: core <core-bounces@ietf.org> On Behalf Of Klaus Hartke
> Sent: Sunday, October 21, 2018 9:04 AM
> To: Christian M. Amsüss <christian@amsuess.com>
> Cc: core@ietf.org WG <core@ietf.org>
> Subject: Re: [core] Modernized Link Format
> 
> 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, though.
> 
> > 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 specifications.
> 
> > Are there yet examples of a
> > .well-known/core file expressed in CoRAL?
> 
> Here's one example from RFC 6690 [3] expressed in CoRAL:
> 
> OLD:
> 
> </sensors>;ct=40;title="Sensor Index",
> </sensors/temp>;rt="temperature-c";if="sensor",
> </sensors/light>;rt="light-lux";if="sensor",
> <http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel="des
> cribedby",
> </t>;anchor="/sensors/temp";rel="alternate"
> 
> NEW:
> 
> #using <http://www.iana.org/assignments/relation/>
> #using lf = <http://TBD/>
> 
> hosts </sensors> {
>     lf:ct "40"
> }
> 
> hosts </sensors/temp> {
>     lf:rt "temperature-c"
>     lf:if "sensor"
>     describedby <http://www.example.com/sensors/t123>
>     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
> "http://www.iana.org/assignments/relation/", 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?
> 
> Klaus
> 
> [1] https://github.com/t2trg/2018-ietf103
> [2] https://tools.ietf.org/html/draft-ietf-core-links-json-10#section-2.3
> [3] https://tools.ietf.org/html/rfc6690#page-14
> [4] https://tools.ietf.org/html/rfc8288#appendix-A.2
> [5] https://www.iana.org/assignments/link-relations/link-relations.xhtml
> [6] https://tools.ietf.org/html/draft-hartke-core-apps-07#section-6.2
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core