Re: [core] Core Link Format
Klaus Hartke <hartke@projectcool.de> Mon, 11 November 2019 15:35 UTC
Return-Path: <hartke@projectcool.de>
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 080DA12089E for <core@ietfa.amsl.com>; Mon, 11 Nov 2019 07:35:57 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 TnwZ0a4exbOv for <core@ietfa.amsl.com>; Mon, 11 Nov 2019 07:35:54 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [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 ietfa.amsl.com (Postfix) with ESMTPS id 6018012023E for <core@ietf.org>; Mon, 11 Nov 2019 07:35:54 -0800 (PST)
Received: from mail-qk1-f175.google.com ([209.85.222.175]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iUBjK-0001p9-Lq; Mon, 11 Nov 2019 16:35:50 +0100
Received: by mail-qk1-f175.google.com with SMTP id q70so11494968qke.12 for <core@ietf.org>; Mon, 11 Nov 2019 07:35:50 -0800 (PST)
X-Gm-Message-State: APjAAAUN04AhxcfUoVoAYaOjovYz3qAyqeb8ew3EYiv1XTwEDpKzK1T0 5QTqQIyuaB2q8f63ueiSY9g9ul4ueO57MMXosQ4=
X-Google-Smtp-Source: APXvYqzqkApDK4XqVDAO6txqp6ujWu7lpjNlTe0boW38g3t1pbRo2UKxXbm5RUv3z5sBAKNgESICXzPlW3fUXGv5UdA=
X-Received: by 2002:ae9:f503:: with SMTP id o3mr10557052qkg.453.1573486549425; Mon, 11 Nov 2019 07:35:49 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR08MB53608C867775D1F1F7051368FA780@VI1PR08MB5360.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR08MB53608C867775D1F1F7051368FA780@VI1PR08MB5360.eurprd08.prod.outlook.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Mon, 11 Nov 2019 16:35:13 +0100
X-Gmail-Original-Message-ID: <CAAzbHvbEDMTxtbnUK7xvLytpFJszYmHoDvEojzcrkJyD4KE1mA@mail.gmail.com>
Message-ID: <CAAzbHvbEDMTxtbnUK7xvLytpFJszYmHoDvEojzcrkJyD4KE1mA@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1573486554; 9694d8fd;
X-HE-SMSGID: 1iUBjK-0001p9-Lq
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Bh8wovevQvbpwDnS5Fx3VWlBb2E>
Subject: Re: [core] Core 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: Mon, 11 Nov 2019 15:35:57 -0000
Hi Hannes, > In previous discussions it was pointed out that Core Link Format has a couple of deficiencies, which motivated the work on Coral. > I was wondering whether there is a write-up available about those problems. I don't have a comprehensive write-up, but a few items from the top of my head below. The limitations of Link Format most frequently show up in CoRE WG meetings where draft authors present exciting new ways to use Link Format for things it was never intended for. Link Format comes with a bunch of weirdnesses and complexities, which makes it difficult to make it accommodate new use cases. CoRAL is more motivated by the need for more expressiveness than the weirdnesses of Link Format. But those weirdnesses exist, to the point, for instance, that draft-ietf-core-resource-directory defines its own Link Format [1]. If you'd like to avoid these weirdnesses and gain more expressiveness (in particular for future evolution), then I think CoRAL would be really interesting for LwM2M. Some issues: * The rules for the context of a link ("...origin of the target URI...") [2] are a constant source of unawareness/confusion and mis-implementation. * The "hosts" link relation type [3] has really, really weird semantics (a featureless relation between a host and a resource, where determining the host relies on the weird rules for the link context). * Despite the appearance of simplicity, parsing Link Format is often more difficult than anticipated by implementers. For example, I've seen implementations that just split the input by ';' and assume that each resulting substring must be one link, regardless of where the ';' occurs. And don't get me started on link attributes with internationalized string values ;-) title*=UTF-8'de'n%c3%a4chstes%20Kapitel * Processing URI references correctly is also really hard to get right. On constrained devices, implementations often don't want to pay the price for a full URI parser and just do some simple string manipulation instead. For example, I've seen implementations that completely disregard the existence of percent encoding and dot segments. URI parsers are also a constant source of fun^H^H^Hsecurity issues [4]. * Link relation types must be registered in the IANA Link Relation Types registry [5]. However, of those registered so far, few are actually useful in the context of IoT - and we probably won't get far flooding the registry with IoT-specific vocabulary. Of course, there are extension link relation types [6], but these are not exactly compact on the wire. * Link target attributes don't even have an IANA registry. * Link target attributes provide information only about link targets. However, it is often very useful to be able to provide also information about the represented resource at the same time. * Link Format only has links that describe how a resource is related to another resource. However, it is often very useful to be able to describe also what you can do with a resource, what parameters are required, etc., when you're extending an API over time. Best regards, Klaus [1] https://tools.ietf.org/html/draft-ietf-core-resource-directory-23#appendix-C [2] https://tools.ietf.org/html/rfc6690#section-2.1 [3] https://tools.ietf.org/html/rfc6690#section-2.2 [4] https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf [5] https://www.iana.org/assignments/link-relations/link-relations.xhtml [6] https://tools.ietf.org/html/rfc8288#section-3.3
- [core] Core Link Format Hannes Tschofenig
- Re: [core] Core Link Format Klaus Hartke
- Re: [core] Core Link Format Carsten Bormann
- Re: [core] Core Link Format Esko Dijk
- Re: [core] Core Link Format Klaus Hartke