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

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

Hello Esko, hello CoRE,

You're right, this does not only come from Limited Link Format, but is
an explicit additional requirement on the lookup side. As I remember,
this was intruduced for two reasons:

* There was little trust in implementations following the RFC6690 rules
  -- they might just as well work under Link Header rules.

* The 6690 rules would require that any present relative anchor would
  need resolution, and in some absent cases, an absent anchor would need
  to be set to a (full) URI.

  Given the varying interpretations of 6690, it would be difficult to
  come up with sharp rules when the anchor could be elided.

Re-reading the 6690 rules, I see that some of my own interpretations of
the resolution process (that, apart from discussions on whether or not
the relation type can have a bearing on the resolution process[1],
seemed to be largely agreed on) can easily have been wrong -- and that
reading played into the "always absolute in lookup" rules.

If what how I think you interpret 6690[2] is the accepted reading of
6690, the explicit anchor can indeed be elided for many cases.

The changes would be manageable on a prescriptive level (but affect a
lot of lookup examples -- removing text from the wire so that's a very
good thing, but still a large change). The three reasons I'm not jumping
to just doing it but ask the WG to chime in are:

* We're quite late in the process.
* If we pick [2] as The Reading of 6690, we should be sure about it, and
  I've been wrong about details of the 6690 process too often to jump to
  conclusions here.
* Very few people using link-format seem to care about the semantics of
  the links in link-format, using it more for the list of resources
  (like, we could have used some resource description format in the
  first place). This makes reviews on preserving the actual link
  semantics -- which we have to to not break the few cases where it does
  matter -- hard to come by.


Chairs, can we even still make such a change?

Esko, does [2] capture how you read the resolution process?

Group, can we find agreement on that being the right interpretation?

KR
Christian

[1]:
> * "anchor" attribute MUST NOT be present for a link with the "hosts"
> relation   (i.e. the default relation if none specified)

This is relatively hard to check -- sure you can test for the presence,
but how about if someone made it explicit as rel=hosts? What about
rel="managed-by hosts"?

[2]: I've read and written too many phrasings of that, maybe this is
less ambiguous -- the RFC6690 algorithm as I think you understand it:

```
docbase = the RFC3986 base URI (from the encapsulating entity, as
  link-format has no base embedded in the content)
href = string part between the angular brackets
anchor = string value of the anchor attribute, or null if absent
target = resolve href against docbase
if anchor == null:
    context = resolve anchor against docbase
else:
    context = origin of target
```

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