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
- [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Christian Amsüss
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Christian Amsüss
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Christian Amsüss
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Jim Schaad
- Re: [core] Modernized Link Format Klaus Hartke
- Re: [core] Modernized Link Format Jim Schaad