Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ?

[Esko Dijk <[e-mail]>]

Hello Christian,

Thanks for the background information. What I don't understand is that you seem to say that Limited Link Format is the cause of a less efficient encoding of link format payloads.
When I look into Appendix C (Github master branch .md) I don't see any rules that there must be an anchor present in particular cases. And I don't see rules that change or simplify Section 2.1 of RFC 6690.

I agree that Link Format can be tremendously complex when all its features are being used, and it is hard to get it right in this case. And yes it has particular flaws (e.g. tremendously inefficient when indicating over coap:// resources hosted on the same host under coaps:// ) 
But I also see that the basic idea of link format for constrained devices is just to use mostly, or exclusively, the "hosts" relation which is the default.
In this case you get nothing more or less than a list of resources, with some optional attributes with it that describe e.g. content format and resource type semantics.

Such a list of resources is quite straightforward to generate, to parse, and to get right I believe.

So what the Limited Link Format Appendix could define in addition is the following rule:
* "anchor" attribute MUST NOT be present for a link with the "hosts" relation   (i.e. the default relation if none specified)

This will lead to the desired, and originally intended, solution for IoT devices that nothing more than a list of URIs is communicated with optional semantic attributes.

So a device serving its own links would respond relative links e.g.
</sensors/temp>;rt=temperature-c;if="sensor",
</sensors/light>;rt=light-lux;if="sensor"

This is simple to interpret as "resources are hosted on the same CoAP endpoint".

A device like an RD serving other's links would respond with absolute links e.g.
<coap://new.example.com/sensors/temp>;rt=temperature-c;if="sensor",
<coap://new.example.com/sensors/light>;rt=light-lux;if="sensor"

This is also simple to interpret as "resources are hosted at the specified CoAP endpoint".
Adding an "anchor" attribute to the above list would only confuse things and the requesting client -- if an IoT device -- wouldn't anyhow use this information! See Section 2.3 of RFC 6690.

To me, it seems we can make Link Format more limited, and simpler, and more efficient at the same time, by the above. And it would also be a true subset of RFC 6690 Link Format.

To make things more clear , and more subset, one can also consider to add the below rule:
* "anchor" attribute MUST be present for a link that specifies a relation ("rel") attribute.   (I.e., that includes a "rel" attribute - and does not use the implicit "hosts" relation.)

So this makes it clear there are 2 types of links possible:
1) Simple "hosts" links that just specify the resource (relative or absolute) - also IoT devices can parse these as a list of links/resources without forming semantic RDF triples internally :)
2) More complex links ( 'subject' <relation> 'object' - semantic statements) that IoT devices are not expected to parse, but more powerful devices could. E.g. a Commissioning Tool.  And there would not be confusion as to what the 'subject' is because that's always specified in the link.


Overall I do not see yet a good reason why the "anchor" attribute is there in the RD draft - given that the simple IoT client may just ignore it (Section 2.3 of RFC 6690) and given that the Appendix C doesn't change the interpretation rules (e.g. Section 2.1 of RFC 6690).
Could you please clarify why it would be useful or good to have the "anchor" attribute there for the "hosts" relation?   Including this seems to make it more rather than less complex I fear.

Of course if we expect this Limited Link Format isn't going to be used much because Coral will eventually replace it, our discussion may be less useful. 

Best regards
Esko

-----Original Message-----
From: Christian Amsüss <[e-mail]> 
Sent: Tuesday, October 20, 2020 12:32
To: Esko Dijk <[e-mail]>
Cc: [e-mail]
Subject: Re: [core] Unnecessary "anchor" attributes in draft-ietf-core-resource-directory-25 ?

Hello Esko,

(picking this to go first as it's the most visible of your comments, and
thanks for all of them),

On Mon, Oct 12, 2020 at 11:25:10AM +0000, Esko Dijk wrote:
> [...] about “anchor” attributes in Link Format that seem unnecessary.
> Hoping this helps to make Link Format documents smaller in size.
>
> This is something I found after reviewing RD again after some years I
> last looked at it.

The issue with the redundancy between anchor and target is that the
RFC6690 link format details about target and anchor are ... well we can
argue about whether they are ambiguous, but they do conflate concepts
(context and base), are hard to read, subtly different from the Link
header and, most importantly, nobody ever implemented them right[1].

Consequently, a compatible subset of link-format and Link headers, that
would be consumable by a wider range of devices, was added as Limited
Link Format (in the RD appendix B). It's admittedly not great at
compression, but at least it works with how people use link-format.

Back when this was added, the hope was that nobody would practically use
text-based link format anyway because links-json[2] (actually, -cbor)
was on the brink of being published. It wouldn't have removed all the
warts, but at least the most pressing ones about resolution. (It would
still have kept the ASCII-delimited arrays for rt and if, and would not
have had a way to set an inline base address, as you'd probably want to
do when returning more than two links from a single endpoint). The
document was withdrawn to avoid churn anticipating a more powerful
solution to the problem (CoRAL), which hasn't landed yet.

(Avoiding too many formats war also why Limited Link Format was born: We
could have done a 6690bis, but feared it'd delay RD too much (hah,
anticipating a publication in 2019), and it would only delay a proper
solution that doesn't need to be held back by the link-format
decisions.)

Does this, to you, explain and justify the choices made about the
link-format representations?

KR
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/D_kuIq6QoBZ86FNniN7G_6d1Rtg/
[2]: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom