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

[Christian Amsüss <[e-mail]>]

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