Subject: [core] RFC5988bis vs RFC6690: interpretation of anchors

From: Christian Amsüss <[email-masked]>
Date: Fri, 6 Oct 2017 14:46:27 +0200

Hello Mark, hello CoRE WG,

reviewing the current 5988bis draft in the course of work on
draft-ietf-core-resource-directory, it seems to me that the update is
fixing a previously ambiguous behavior to be different to how 6690 has
disambiguated it -- the question is:

Whether the target IRI is resolved relative to the link context IRI or
the document context IRI.

* 5988 prescribes that the relative target references are resolved per
  3986 (not applying base IRIs from the message's content, which I read
  as data inside the response body like an HTML base-href).

  This leaves it unclear whether the "Context" of the link (defined in
  the next paragraph) also serves as the context as the term is used in
  3986 section 5.

* 6690 section 2.1 explains that the context is just another word for
  Base URI ("context URI of a link (also called the base URI in
  RFC39)"), and that the anchor sets such a context. This implies that
  if an anchor is set, the target reference is resolved relative to the
  resolved anchor.

* 5988bis does not change the relevant wording, but the algorithm in
  Appendix B clearly resolves target before resolving context, so both
  the target_string and the context_string are resolved relative to the
  document URI.

None of documents has examples where the it actually matters whether or
not target_string is relative to context_string or to the document
base URI.

Was the decision to clarify the behavior this way made in awareness of
RFC6690 building on the original document interpreting otherwise? If
not, could you consider the alternative behavior? Or are there other
applications or documents that are already set on the new one?

If this stays as it is in the latest 5988bis, will the text in RFC6690
be considered erroneous, or will application/link-format diverge from
link headers?

In resource-directory, we *will* need to give examples of what a link
looks like when served from a different URI, and to give guidance as to
how a directory should parse the links -- so what can we assume?

Thanks
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Oct 2017 11:28:44 -0700

Hi Christian et al,

> On 6 Oct 2017, at 5:46 am, Christian Amsüss <[email-masked]> wrote:
> 

That's not ambiguous at all. 3986 only uses "context" casually; the formal term is defined as "base uri" in 5.1.

When introducing what links are, 5988 says:

"""
A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}".
"""

How does this countenance that reading?

>  if an anchor is set, the target reference is resolved relative to the

That's diverging from 5988. 

> RFC6690 building on the original document interpreting otherwise?

No.

> If not, could you consider the alternative behavior?

No; doing so would break Web linking pretty fundamentally.

> Or are there other

It's not new. AFAIK, 6690 is the only ones that interpreted it this way.

> be considered erroneous, or will application/link-format diverge from

I think that's up to you.

> how a directory should parse the links -- so what can we assume?

I'm not sure what you're looking for here.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 11 Oct 2017 18:48:00 +0200

Hello Mark,

thanks for your fast and unambiguous response.

On Mon, Oct 09, 2017 at 11:28:44AM -0700, Mark Nottingham wrote:
> That's not ambiguous at all. 3986 only uses "context" casually; the
> formal term is defined as "base uri" in 5.1.
> 
> A link can be viewed as a statement of the form "{context IRI} has a
> {relation type} resource at {target IRI}, which has {target
> attributes}".
> """
> 

That sentence doesn't; it's the informal use of context that did, when
read without keeping normative and non-normative language apart
stictly.

At any rate, with the algorithm in 5988bis the intention is fixed, and
we'll need to think of how to resolve the resulting discrepancies with
6690 and its users.

So, hello working group,

> > * 6690 section 2.1 explains that [...] if an anchor is set, the
> > target reference is resolved relative to the resolved anchor.
> 

So how do we go about this?

If CoRE insists on sticking with the divergence it's fine with me, but I
assume it doesn't. And if so, we'd need to state that explicitly in
resource-directory, and I'd prefer not to only start this discussion
when it goes through late review stages.

Otherwise, given that we can't change that in an erratum, the next
logical step would be a 6690bis document that makes a clear cut and
changes the link semantics to the 5988 ones.

The published documents that reference 6690, from my brief survey, do
not really touch on the semantics of links; the one affected most deeply
is RFC7089, and given it is used in an HTTP context together with Link
headers, I consider it unlikely that applications actually implement the
diverging behavior of 6690 for link-format bodies. The document does
give special rules for the links' interpretation, though, which use
Context as a formal term.

> I'm not sure what you're looking for here.

Guidance from the working group as to which direction this will take,
and how this topic can come to a conclusion without holding up
resource-directory for cycles.

Thanks
Christian

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 11 Oct 2017 19:23:49 -0700

> -----Original Message-----
> From: core [mailto:[email-masked]] On Behalf Of Christian Amsüss
> Sent: Wednesday, October 11, 2017 9:48 AM
> To: [email-masked] WG ([email-masked]) <[email-masked]>; Mark Nottingham
> <[email-masked]>
> Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors
> 
> Hello Mark,
> 
read
> without keeping normative and non-normative language apart stictly.
> 
we'll
> need to think of how to resolve the resulting discrepancies with
> 6690 and its users.
> 
> So, hello working group,
> 
assume
> it doesn't. And if so, we'd need to state that explicitly in
resource-directory,
> and I'd prefer not to only start this discussion when it goes through late
> review stages.
> 
> Otherwise, given that we can't change that in an erratum, the next logical
> step would be a 6690bis document that makes a clear cut and changes the
> link semantics to the 5988 ones.

Given the proposed definition of the "at" parameter, I think we should kill
the current usage of anchor and figure out exactly how we want to use "at"
and "con" to do this instead.  For that purpose, I think that we need to do
an update of RFC 6690 to correct this algorithm and provide one using one or
both of the other parameters.  It is not clear to me that 'at' and 'con' are
both needed so that should be discussed as well.

Another thing that is part of this which I have not yet fund, is the
question of what the context should be when things are pulled from the
/.well-known/core location.  The context according to the defined algorithm
would include that path and I do not believe that is what anybody things
should be happening.

Jim

> 
> The published documents that reference 6690, from my brief survey, do not
> really touch on the semantics of links; the one affected most deeply is
> RFC7089, and given it is used in an HTTP context together with Link
headers, I
> consider it unlikely that applications actually implement the diverging
> behavior of 6690 for link-format bodies. The document does give special
> rules for the links' interpretation, though, which use Context as a formal
> term.
> 
> > > In resource-directory, we *will* need to give examples of what a
> > > link looks like when served from a different URI, and to give
> > > guidance as to how a directory should parse the links -- so what can
we
> assume?
> Guidance from the working group as to which direction this will take, and
> how this topic can come to a conclusion without holding up resource-
> directory for cycles.
> 
> Thanks
> Christian
> 
> --

---

From: 'Christian Amsüss' <[email-masked]>
Date: Thu, 12 Oct 2017 09:28:38 +0200

Hello Jim,

On Wed, Oct 11, 2017 at 07:23:49PM -0700, Jim Schaad wrote:
> and "con" to do this instead.

I was thinking more along the lines of a minimal patch (given that con=,
as of now, is a purely RD internal attribute without any effect on
link-format parsing or interpretation, short of under-the-rug corner
cases we try to avoid).

Of course, using con=/at= (from my last talk with protocol-negotiation
authors, I think that we can have con= everywhere in the output) to
explicitly set a base URI at the metadata level would have its merits.
But I don't quite see how this can be done in a compatible way, and how
not every link-format request then means that .well-known/core has to be
available in parsed form too to see whether there's a con in the
metadata. (Or would a `<>;rel=self;con="x"` have the same effect as an
HTML <base href="x">, inline setting the Base URI?)

I would like that, and be happy to discuss it, (for example because it
could save quite some message size in RD resource lookups), but am
conflicted because anything that's not a re-publication with fixes
applied has the potential for holding up RD even further.

> would include that path and I do not believe that is what anybody things

Yes, that's the second ting a 6690bis should solve. I think that it's
practically not so pressing because the ambiguity is easy to work around
by all links in .w-k/c starting with at least a slash (which they
usually do) and because the hosts relation is not used too much, but
still we should have an answer to that.

Thanks for your response
Christian

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 12 Oct 2017 18:50:03 +0200

Hello Working Group,

> That's diverging from 5988. 

from the last resource-directory meeting, the takeaway is that RFC6690
link-format serialization already does some other things differently
than Link-Headers, and that having the target resolve relative to the
anchor is a practical thing to do in the context of standalone
documents.

The next version of resource-directory will be more explicit about how
relative references are resolved into URIs, and possibly lining out the
differences to Link headers in preparation for a more explicit 6690bis,
without any urgency for such a document.

I'm not convinced personally that it's the best way to go about it, but
I see that it makes some things easier (so I'd hapily participating in
any further discussion ensuing from this).

Best regards
Christian

---

From: Jim Schaad <[email-masked]>
Date: Thu, 12 Oct 2017 10:32:43 -0700

Greetings Christian,

> From: 'Christian Amsüss' [mailto:[email-masked]]
> Sent: Thursday, October 12, 2017 12:29 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> > Given the proposed definition of the "at" parameter, I think we should
> > kill the current usage of anchor and figure out exactly how we want to
use
> "at"
as of
> now, is a purely RD internal attribute without any effect on link-format
> parsing or interpretation, short of under-the-rug corner cases we try to
> avoid).
> 
explicitly
> set a base URI at the metadata level would have its merits.
not
> every link-format request then means that .well-known/core has to be
> available in parsed form too to see whether there's a con in the metadata.
> (Or would a `<>;rel=self;con="x"` have the same effect as an HTML <base
> href="x">, inline setting the Base URI?)

My problem with this approach is that, given what I understand how "at" to
be defined, it should just replace "con" completely.  Therefore starting to
use con and then making it go away seems to me to be a bad idea.  Even if we
just define the use of "at" with one item and then allow or it later to
become two items seems to me to be a better approach.

Jim

> I would like that, and be happy to discuss it, (for example because it
could
> save quite some message size in RD resource lookups), but am conflicted
> because anything that's not a re-publication with fixes applied has the
> potential for holding up RD even further.
> 
> > /.well-known/core location.  The context according to the defined
> > algorithm would include that path and I do not believe that is what
> > anybody things should be happening.
> 
practically
> not so pressing because the ambiguity is easy to work around by all links
in
> .w-k/c starting with at least a slash (which they usually do) and because
the
> hosts relation is not used too much, but still we should have an answer to
> that.
> 
> Thanks for your response
> Christian
> 
> --