[core] RFC5988bis vs RFC6690: interpretation of anchors

[Christian Amsüss]

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

[Mark Nottingham]

Hi Christian et al,

Post by Christian Amsüss
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
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.

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?

Post by Christian Amsüss
* 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.

That's diverging from 5988.

Post by Christian Amsüss
* 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?

No.

Post by Christian Amsüss
If not, could you consider the alternative behavior?

No; doing so would break Web linking pretty fundamentally.

Post by Christian Amsüss
Or are there other
applications or documents that are already set on the new one?

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

Post by Christian Amsüss
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?

I think that's up to you.

Post by Christian Amsüss
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?

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

Cheers,

Post by Christian Amsüss
Thanks
Christian
--
There's always a bigger fish.
-- Qui-Gon Jinn

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

[Christian Amsüss]

Hello Mark,

thanks for your fast and unambiguous response.

Post by Mark Nottingham
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}".
"""
How does this countenance that reading?

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,

Post by Mark Nottingham

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

That's diverging from 5988.

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.

Post by Mark Nottingham

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?

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

[Jim Schaad]

-----Original Message-----
Sent: Wednesday, October 11, 2017 9:48 AM
Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors
Hello Mark,
thanks for your fast and unambiguous response.

Post by Mark Nottingham
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}".
"""
How does this countenance that reading?

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,

Post by Mark Nottingham

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

That's diverging from 5988.

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.

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.

Post by Mark Nottingham

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?

Post by Mark Nottingham
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

['Christian Amsüss']

Hello Jim,

Post by Jim Schaad
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.

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.

Post by Jim Schaad
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.

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

[Jim Schaad]

Greetings Christian,

-----Original Message-----
Sent: Thursday, October 12, 2017 12:29 AM
Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors
Hello Jim,

Post by Jim Schaad
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"

Post by Jim Schaad
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?)

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.

Post by Jim Schaad
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.

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
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom

[Christian Amsüss]

Hello Working Group,

Post by Mark Nottingham
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