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

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

Hello Esko,

On Wed, Oct 21, 2020 at 12:59:59PM +0000, Esko Dijk wrote:
> I've swapped two lines in your item [2] plus added some comments for
> clarification

The swapping resolved a refactoring error of mine -- so we are aligned
there.

> Because this may be multi-interpretable, my idea for Limited Link
> Format was to simplify the parsing by splitting into two possible
> cases: 1) implicit rel=hosts without 'anchor' ; and 2) any other link
> with 'anchor'.

It the above reading is agreed on, the rule can even be simpler: "If
anchor was absent originally, it can stay absent". That would catch the
same cases and some more, not depend on understanding rel, and upset the
same set of implementations (those based on the 2018 understanding, and
AFAIK that means it's only mine).

> 1* "anchor" attribute MUST NOT be present for any link without the "rel" attribute   (this implies that this link uses the implicit rel=hosts semantics only)
> 2* "anchor" attribute MUST be present for any link with the "rel" attribute                  (this could be any type of link, possibly using rel="managed-by hosts" or rel="hosts" or rel=hosts )

If we go that route (and at least a brief chair chat earlier today
sounded a bit reluctant), I'd revisit the known implementations. My
expectation is that these restrictions won't even be necessary.

The main offender that necessitated the full-anchor-everywhere was my
2018 understanding. The change would be to reiterate in Limited Link
Format that unlike in the Link header, an absent anchor means the
context is origin-of(resolved-target), and then no further conditions on
rel need apply.

So probably it'd be either leave-it-and-say-why-it's-like-that, or going
even a step further than you are suggesting.

> There is one more consideration for the current RD draft - in case we
> decide to keep the explicit "anchor" attribute in all the examples.
> Because RFC 6690 is a normative reference, the assumption of the
> reader currently should still be that the "anchor" attribute that's
> added in all the example is just superfluous i.e.
>
> * an RD implementation may elide it , following RFC 6690 rules  (in
>   the interpretation as coded at the top of this email.) and Section
>   2.3 of 6690

I disagree here -- just because we normatively use 6690 doesn't mean we
can't profile it and prescribe that a particular serialization needs to
be used.

> * an RD client doing lookups may ignore it, following RFC 6690 rules
> in Section 2.3

... and here: 6690 says that "A consuming implementation can, however,
choose to ignore such links." (and not such attributes). The client woud
just ignore all resource lookup results, and the implementer would thus
need to implement (at least rudimentary) support for the anchor
attribute.

KR, and thanks for all your input
Christian

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