Re: [core] Core Link Format

Klaus Hartke <hartke@projectcool.de> Sun, 17 November 2019 07:09 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 810081200A1 for <core@ietfa.amsl.com>; Sat, 16 Nov 2019 23:09:31 -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 dK_gQTVtS8SI for <core@ietfa.amsl.com>; Sat, 16 Nov 2019 23:09:29 -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 4475F120041 for <core@ietf.org>; Sat, 16 Nov 2019 23:09:28 -0800 (PST)
Received: from mail-qk1-f180.google.com ([209.85.222.180]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iWEgY-0007Hg-LY; Sun, 17 Nov 2019 08:09:26 +0100
Received: by mail-qk1-f180.google.com with SMTP id 15so11728214qkh.6 for <core@ietf.org>; Sat, 16 Nov 2019 23:09:26 -0800 (PST)
X-Gm-Message-State: APjAAAVYWNveXWXagEhK/d9QTxnAOTS0sW7PeS6xW3QcGM3jVJYRbFxY FTb5y3uYN9GqgzoBCVJR2Qrk64KdIT77zJldw+E=
X-Google-Smtp-Source: APXvYqyNzQMQbES7+FZ8uJzO8Rm+H8GpWdiz+7u3doI4OD0bU80mGO6fBmO/doaxIdiRhBXp/LBllp6BlGo5VruQGf4=
X-Received: by 2002:a37:76c6:: with SMTP id r189mr18481655qkc.303.1573974565454; Sat, 16 Nov 2019 23:09:25 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR08MB53608C867775D1F1F7051368FA780@VI1PR08MB5360.eurprd08.prod.outlook.com> <CAAzbHvbEDMTxtbnUK7xvLytpFJszYmHoDvEojzcrkJyD4KE1mA@mail.gmail.com>
In-Reply-To: <CAAzbHvbEDMTxtbnUK7xvLytpFJszYmHoDvEojzcrkJyD4KE1mA@mail.gmail.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Sun, 17 Nov 2019 08:08:49 +0100
X-Gmail-Original-Message-ID: <CAAzbHvYBgkpMQnB7ofpXnapzHMTqPYB166mogJWpt+vHo0gPhA@mail.gmail.com>
Message-ID: <CAAzbHvYBgkpMQnB7ofpXnapzHMTqPYB166mogJWpt+vHo0gPhA@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; 1573974569; bf78ed52;
X-HE-SMSGID: 1iWEgY-0007Hg-LY
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ndHX8Y7wCB8YrjrrKpKQRIj6nDw>
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: Sun, 17 Nov 2019 07:09:31 -0000

I tried to remember where I had seen those broken Link Format
implementations. I've found some of them now again. It's Leshan and
Wakaama:

> * The rules for the context of a link ("...origin of the target
> URI...") [2] are a constant source of unawareness/confusion and
> mis-implementation.

Wakaama seems to completely ignore the existence of the 'anchor' attribute. [1]

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

Wakaama seems to completely ignore the existence of link relation types. [1]

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

(Of course, links are separated by ',' and not ';'.)

Leshan splits by ',', regardless of where the ',' occurs. [2]

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

Wakaama doesn't seem to do any kind of percent encoding or dot segment
processing. [1]

Overall, it seems that LwM2M implementations are interoperable on the
basis of an informally-specified subset of Link Format. That might
work out for LwM2M, but I think it highlights exactly the problem with
Link Format. :-)

Klaus

[1] https://github.com/eclipse/wakaama/blob/31d64c0c41fae9653c1fa53ef58d1a44e49017fa/core/registration.c#L1279-L1447

[2] https://github.com/eclipse/leshan/blob/f512b574797e852f8e883641ab0df852bebb7fcd/leshan-core/src/main/java/org/eclipse/leshan/Link.java#L119-L160