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

[Esko Dijk <[e-mail]>]

PS one additional remark to my previous email.

In the present link examples obtained from RD we may have:

<coap://[2001:db8:3::123]:61616/temp>;rt="tag:example.org,2020:temperature";anchor="coap://[2001:db8:3::123]:61616"

I was wondering what parsing problems would arise in the client if it were returned without the 'anchor':

<coap://[2001:db8:3::123]:61616/temp>;rt="tag:example.org,2020:temperature"

That seems clear; from this answer - how could anyone be mistaken about the anchor i.e. which server is hosting the '/temp' resource ? There's only one server mentioned so that's the one right :)    
And for the rel=hosts relation it would not make much sense to proclaim e.g. "coap://server1  hosts  coap://server2/resource"  ... 

Best regards
Esko

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

Hello Christian,

Thanks for the helpful response. I've swapped two lines in your item [2] plus added some comments for clarification; below is my understanding:

```
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 = origin-of ( target )             # Section 2.1 rule (b) and (c). If href is ABNF 'URI' then this is origin-of(href), if href 'relative-ref' then origin-of(docbase).
else:
    context = resolve anchor against docbase       # Section 2.1 rule (a) - if anchor is ABNF 'URI' then result of resolution is again 'anchor'. If ABNF 'relative-ref' then result is "docbase / relative-ref"
```

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'.
Then for parsers that would accept category 2) they can remove the above "anchor==null" case in the parsing, which simplifies it.  And IoT devices could just ignore any such 'complex' links that specify a 'rel' and an 'anchor'. (As is also expected per RFC 6690); and only parse case 1) links.
Case 1) is the simple "list of links" which is easier to interpret than the more general case 2).

Base on your comment [1] I see that my proposed rule needs some update to do this properly:  what about 2 rules:
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 )

So then the only case where "anchor" can be elided is the case of using the implicit 'rel=hosts' relation, achieved by leaving out the "rel" attribute.

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
* an RD client doing lookups may ignore it, following RFC 6690 rules in Section 2.3

So we still will be faced with interoperability issues if RD implementers interpret RFC 6690 differently.   What is needed in this case is that we *update* RFC 6690 rules explicitly e.g. by making "anchor" mandatory in all cases.  (Whether we formally update RFC 6690 or just define it as part of Limited Link Format doesn't matter that much I think.)

Best regards
Esko


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

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
_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core