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

[Esko Dijk <[e-mail]>]

Hello Christian,

> statement like coap://server1 hosts coap+sms://[phone]/ might make
> a bit more sense, and the tautological definition of the relation

To me this looks as if not intended by RFC 6690 , because the server coap://server1 is a different server than the one on coap+sms://[phone] .  At least per RFC 7252, one server is one endpoint. So different endpoint is always a different server, or not?
(Interesting to note is that for clients it is similarly defined in RFC 7252, if a CoAP client changes its outgoing UDP port it becomes a different client.)

> The description in RFC6690 Section 2.2 doesn't help either; it
> potentially makes it worse by claiming that hosts only works with
> relative references in the target. That statement is probably what

Agree that the MUST statement there is problematic - I initially interpreted it as #1 below: 

** Interpretation #1
"resource indicated by the target URI MUST be a URI that can be potentially described as a relative reference with respect to context-URI used as base URI"
-> then 'coap://server1 hosts /test' would be valid.
-> then 'coap://server1 hosts coap://server1/test' would be valid.
-> then 'coap://server2 hosts coap://server1/test' would be invalid.

** Interpretation #2
But it could also be interpreted as
"target URI MUST be a URI of the ABNF form 'relative-ref' , and the target URI MUST be a relative reference with respect to context-URI used as base URI"
-> then 'coap://server1 hosts /test' would be valid.
-> then 'coap://server1 hosts coap://server1/test' would be invalid.
-> then 'coap://server2 hosts coap://server1/test' would be invalid.

If a majority of people interprets like #1, then we don't have to update/correct RFC 6690 and we can define a profile of Limited Link Format. And clarify a bit how we should read 6690.
If however most people interpret as #2, then current RD usage of rel=hosts for absolute target URI is incorrect and we would need to formally update RFC 6690 I think to make that possible.

> fueled my (probably mis?)conception about the target being resolved
> relative to the anchor, as only then it makes sense. (Salvaging it by

I assume for the moment the interpretation #1 as above. The target needs to be resolved relative to the context URI as per the Section 2.2 MUST requirement. The
context URI could be an explicit URI given by the 'anchor' attribute but it may also use the default, if that's not given.  If the target URI is an absolute URI
form then the default context URI becomes the origin of that target URI. So the MUST relation always holds true if the target URI is written in
an absolute URI form.   So in this case it (to me) makes sense that including any anchor parameter is not necessary in that case, even superfluous.

How to proceed with the issue of the different interpretations #1/#2?

Best regards
Esko

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

On Wed, Oct 21, 2020 at 01:21:42PM +0000, Esko Dijk wrote:
> 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"  ... 

That's intuitively clear for coap://server1 and coap://server2, but a
statement like coap://server1 hosts coap+sms://[phone]/ might make
a bit more sense, and the tautological definition of the relation
doesn't help much there. As the meaning is so vague, I'm loathe to make
precise rules depend on it.

The description in RFC6690 Section 2.2 doesn't help either; it
potentially makes it worse by claiming that hosts only works with
relative references in the target. That statement is probably what
fueled my (probably mis?)conception about the target being resolved
relative to the anchor, as only then it makes sense. (Salvaging it by
saying there can't be an anchor with a hosts relation would just make it
worse by breaking RD).

KR
c

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