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

[Esko Dijk <[e-mail]>]

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

The proposed rule sounds good. It's easier to understand and apply for implementers than what I proposed.
So if the registering client sends its list of relative links without any 'rel' attribute in there nor 'anchor', the RD serves them back to lookup clients as absolute URIs without any 'rel' nor 'anchor' - unmodified statements, except for the change of relative URI to absolute URI.

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

Yes, agree.  That would be good to clarify/profile.

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

Okay, I'm hoping the outcome would be the one where the 'anchor' attributes are not added by the RD. (Per above text)

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

Agree that we can make a profile of RFC 6690 and not update it!  (as long as we don't violate any existing 6690 rules).
Sorry if I wasn't fully clear here.  In the case of the current RD draft text, the profile would need to say e.g. "the Limited Link 
Format serialization created by RD-lookup response must include the 'anchor' attribute in each link".
This is needed to clarify why all the examples use the 'anchor' while 6690 doesn't require it. And also to clarify that
RD implementations cannot use the shorter variant without 'anchor' even though 6690 would allow it.

Best regards
Esko

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

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