Re: [core] Core Link Format

[Klaus Hartke <[e-mail]>]

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