Subject: Re: editorial LC comments on draft-nottingham-http-link-header-07.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Feb 2010 16:31:50 +1100

On 22/01/2010, at 1:04 AM, Julian Reschke wrote:
> Section 9.1., paragraph 9:
> OLD:
> 
>   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
>              Languages", RFC 4646, September 2006.
> 
> NEW:
> 
>   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
>              May 2008.

Did you mean to replace 4646 with 5646 here?

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Feb 2010 17:17:58 +1100

I think perhaps you need to talk to Roy about that...

At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by updating the document, for parameters common to many relation types, or on a per-type / per-application basis). 

On 22/01/2010, at 8:09 PM, Julian Reschke wrote:

>>> Later on, in the section about HTML4 we find (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>):
>>> 
>>>  HTML4 also has a "rev" parameter for links that allows a link's
>>>  relation to be reversed.  The Link header does not define a
>>>  corresponding "rev" parameter to allow the expression of these links
>>>  in HTTP headers, due to the confusion this mechanism causes as well
>>>  as conflicting interpretations (briefly, some hold that rev reverses
>>>  the direction of the link, while others that it reverses the
>>>  semantics of the relation itself).
>>> 
>>> I have to admit that I'm still not sure what *in practice* the difference between reversing the link direction and reversing the link semantics actually is. (Example?)
>> I can add a brief example for the latter.
> 
> Please.
> 
>>> So my preference would be to actually define the rev parameter consistently with this, and then to discourage it's use due to the other good reasons we heard about that (such as HTML authors typing "rev" instead of "rel").
>> As previous discussed (quite a bit), HTML2 defines REV as having reversed *semantics*, while HTML4 talks about it creating a "reverse link" -- which are very different things. This feels like a rat hole to me (thus my attempts to navigate around it).
> 
> Again, HTML 2 defines it as:
> 
>    REV
>            same as the REL attribute, but the semantics of the
>            relationship are in the reverse direction. A link from A
>            to B with REL="X" expresses the same relationship as a
>            link from B to A with REV="X". An anchor may have both
>            REL and REV attributes.
> 
> (<http://tools.ietf.org/html/rfc1866#section-5.7.3>)
> 
> That totally sounds like "reverse link" to me. So, I really really think there's less confusion than some people claim.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 04 Feb 2010 10:36:47 +0100

On Thu, 04 Feb 2010 07:17:58 +0100, Mark Nottingham <[email-masked]> wrote:
> At the moment, my intent is to remove 'rev' from the BNF and state how  
> new parameters can be added (either by updating the document, for  
> parameters common to many relation types, or on a per-type /  
> per-application basis).

+1

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Feb 2010 16:58:17 +0100

> At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by updating the document, for parameters common to many relation types, or on a per-type /…

-1 / +1

Yes, the extensibility point should be documented.

But no, rev should be documented. RFC 2068 already defines what it is, 
so the only thing an extension could ever do is to re-introduce that 
definition.

There may be good reasons to *discourage* it's use, but that's really 
different from not defining it at all.

I think we should park this issue until we know what happens with the 
anchor parameter; after all, a link relation using rel= can always be 
rewritten into one using anchor=.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Feb 2010 11:08:20 +1100

On 05/02/2010, at 9:07 AM, Roy T. Fielding wrote:

> On Feb 3, 2010, at 10:17 PM, Mark Nottingham wrote:
> 
> I think we are going around in circles.

Yes, I've been feeling that way for some time now...

> The normal way to document a
> deprecated protocol feature is to include it in the ABNF and state
> that it is deprecated in the prose.  Just like obs-text in HTTP.
> Otherwise, we'll just keep getting asked "what happened to rev?"  

Please make a proposal with text. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Feb 2010 11:23:56 +1100

On 29/01/2010, at 11:45 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> ...
>> If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you? ...
> 
> First of all, I'd prefer to distinguish between (A) "must be processed" and (B) "may be processed, otherwise link must be rejected altogether".
> 
> I see two purposes for the anchor parameter:
> 
> 1) Making a statement about a subset of the context resource, by specifying a fragment identifier
> 
> 2) Making a statement about a different resource than the context resource, such as
> 
> 2a) because the context is anonymous (such as the response body for a 204, see <http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-07.html#rfc.section.A.1>), or
> 
> 2b) because a reverse link is exposed (anchor as workaround for missing rev parameter)
> 
> I'm still not sure why we would ever make special cases here, except for the known bugs in current implementations of the Link header where anchor is ignored (so mainly Mozilla/Opera for stylesheet links). Optimally, we just work with the vendors to get the bugs fixed.
> 
> If that's not possible, allowing an opt-out per relation type might work, as long as behavior (B) would still be allowed. Is there any relation != "stylesheet" for which this would be relevant?

I think most of them.

E.g., what happens when my weblog
  http://www.mnot.net/blog/
contains a link header
  Link: </blog-publish>; rel="service"; anchor="http://www.intertwingly.net/blog/"
?
After Sam visits my blog, should his browser (assuming it supports Atompub) use my site for editing next time he wants to post something?

Likewise, what happens after I put this link header in all of my responses?
  Link: <http://www.yahoo.com/>; rel="self"; anchor="http://www.google.com/"
?

Or better yet:
  Link: <http://www.mybank.com.au/mnot>; rel="payment"; anchor="http://www.amazon.com/"

While it may be that browsers in general won't "remember" this information, that doesn't mean that we should specify things so that they're encouraged to handle these things, knowing full well that they won't. Opt-in seems much more sane that opt-out here, at least for different resources.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Feb 2010 13:24:32 +0100

Roy T. Fielding wrote:
> I think we are going around in circles.  The normal way to document a

Indeed.

> ...
> A reverse link would show up as a potential transition from B if
> you are currently at B.  That terminology is from hypertext research
> where link servers would maintain a database of all links.  That is
> why the HTML4 definition is confusing to folks who have worked with
> traditional hypertext systems, since the Web does not maintain reverse
> links (other than via external services like a CMS or Google).
> 
> Anyways, it doesn't matter whether people are confused or not.
> What matters is that the HTML2 definition of rev defines how the
> technology actually works, whereas the HTML4 definition adds a
> bunch of hand-waving and then misuses hypertext terminology in
> order to explain what it "means" -- the result is neither technically
> correct nor consistent with other hypertext systems, even if it
> can be read the same way if we twist our heads a certain direction,
> close one eye, and pretend we are in Kansas.
> ...

HTML5 doesn't have rev anymore anyway (well, unless the WG changes this 
again)

So why don't we just say that "rev" means what HTML2 used to say, and be 
done with it?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Feb 2010 13:38:28 +0100

> After Sam visits my blog, should his browser (assuming it supports Atompub) use my site for editing next time he wants to post something?

That's an excellent example. I do agree that - in general - we don't 
want <http://www.mnot.net/blog/> to be able to affect 
<http://www.intertwingly.net/blog/>.

So the choices here are:

a) Processing anchor, detecting the authority conflict, and ignoring the 
link, or

b) ignoring anchor, and pretending we have <http://www.mnot.net/blog/> 
--service--> <http://www.mnot.net/blog/blog-publish>

What I'm trying to say is that we never ever want b).

So I'm fine with clients ignoring the link header altogether because it 
contains anchor, but simply ignoring the anchor parameter, but 
processing the rest seems to be a very bad idea.

> While it may be that browsers in general won't "remember" this information, that doesn't mean that we should specify things so that they're encouraged to handle these things, knowing full well that…

Well, maybe we've been agreeing all the time, and just the spec text 
needs tuning.

So again: a recipient MUST resolve the anchor parameter against the 
context IRI (*), producing a new context. It MAY ignore the link if the 
resulting context looks suspicious (maybe something like same-domain 
could be recommended here).

Best regards, Julian

(*) + handle the case where there's no context IRI

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 4 Feb 2010 14:07:31 -0800

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Feb 2010 17:14:11 +1100

On 05/02/2010, at 11:24 PM, Julian Reschke wrote:
> 
> HTML5 doesn't have rev anymore anyway (well, unless the WG changes this again)
> 
> So why don't we just say that "rev" means what HTML2 used to say, and be done with it?

Because (IMO) implementation experience has shown that rev= is horribly confusing* to developers, and will cause more problems than it solves; it's much better to just register a different relation (even if that does offend those who like tidiness). 

I'd be OK with putting it in the BNF, giving the HTML2 explanation, and deprecating it in prose, though. 

* For those who dispute this, have a look at blog and other discussions of rev=canonical; it tripped up a lot of people.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Feb 2010 09:24:19 +0100

> I'd be OK with putting it in the BNF, giving the HTML2 explanation, and deprecating it in prose, though. 

That sounds good to me.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 19 Feb 2010 13:03:54 +1100

OLD:
  The anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application in use.

NEW:
  Links with the anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application and/or relation type in use.

works?

On 05/02/2010, at 11:38 PM, Julian Reschke wrote:

> That's an excellent example. I do agree that - in general - we don't want <http://www.mnot.net/blog/> to be able to affect <http://www.intertwingly.net/blog/>.
> 
> So the choices here are:
> 
> a) Processing anchor, detecting the authority conflict, and ignoring the link, or
> 
> b) ignoring anchor, and pretending we have <http://www.mnot.net/blog/> --service--> <http://www.mnot.net/blog/blog-publish>
> 
> So I'm fine with clients ignoring the link header altogether because it contains anchor, but simply ignoring the anchor parameter, but processing the rest seems to be a very bad idea.
> 
> Well, maybe we've been agreeing all the time, and just the spec text needs tuning.
> 
> So again: a recipient MUST resolve the anchor parameter against the context IRI (*), producing a new context. It MAY ignore the link if the resulting context looks suspicious (maybe something like same-domain could be recommended here).
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Feb 2010 10:31:14 +0100

>    Links with the anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application and/or relation type in use.

That's better, in that it clarifies that the anchor parameter never ever 
can be ignored.

However, it still delegates the decision to the "fuzzy" term 
"application" or the relation type registration (why would that be 
involved?).

How about:

"The presence of the anchor parameter affects the context IRI. Thus, 
consumers either MUST ignore all links that include the anchor 
parameter, or process it according to <ref>. In the latter case, the 
resulting context IRI can identify an entirely different resource, in 
which case consumers MAY choose to ignore the link."

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 26 Feb 2010 15:44:57 +1100

What's <ref> here? I still don't see where the decision is made... at worst, this makes it seem like consumers can make an arbitrary decision as to whether to process a link with an anchor.

This is where I am now:

  Links with the anchor parameter MUST be ignored by consuming implementations, unless their use is explicitly specified.

On 19/02/2010, at 8:31 PM, Julian Reschke wrote:

> That's better, in that it clarifies that the anchor parameter never ever can be ignored.
> 
> However, it still delegates the decision to the "fuzzy" term "application" or the relation type registration (why would that be involved?).
> 
> How about:
> 
> "The presence of the anchor parameter affects the context IRI. Thus, consumers either MUST ignore all links that include the anchor parameter, or process it according to <ref>. In the latter case, the resulting context IRI can identify an entirely different resource, in which case consumers MAY choose to ignore the link."
> 
> Best regards, Julian
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Feb 2010 10:49:21 +0100

On 26.02.2010 05:44, Mark Nottingham wrote:
> What's<ref>  here? I still don't see where the decision is made... at worst, this makes it seem like consumers can make an arbitrary decision as to whether to process a link with an anchor.

<ref> would point to text that states how to resolve against the context 
IRI when present.

And yes, I think consumers can make an almost arbitrary decision about 
it -- either they ignore the syntax they don't grok, or they process it 
as specified (where there's really only a single way to process them).

>    Links with the anchor parameter MUST be ignored by consuming implementations, unless their use is explicitly specified.

That doesn't work for me, as it makes it sound that somebody needs to do 
additional work to "specify" it. Who? And what? The only thing that 
needs to be said is that the anchor param modifies the context, and 
recipients are allowed to ignore it if the resolved context IRI differs 
from the original one.

So how about (adding more context):

"The anchor parameter overrides this with another URI, such as a 
fragment of this resource, or a third resource (i.e., when the anchor 
value is an absolute URI).  If the anchor parameter's value is a 
relative URI, parsers MUST resolve it as per [RFC3986], Section 5.  Note 
that any base URI from the body's content is not applied.

Note that the presence of the anchor parameter affects the context IRI. 
Thus, consumers either MUST ignore all links that include the anchor 
parameter, or process it according to its definition above. In the 
latter case, the resulting context IRI can identify an entirely 
different resource, in which case consumers can choose to ignore the link."

(We might have to tune the paragraph for the case where the context 
resource is anonymous, though)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 28 Feb 2010 22:22:02 +1100

I think we're saying the same thing here, but your text seems to rely upon the reader to understand that it's underspecified purposefully (the "syntax they don't grok"), whereas I'd like to surface that in the document.

I know it's a bit messy, but there *is* a concept of something that says "when you're using links for X, this is valid, this isn't." 

I.e., consumers don't just pick a number from /dev/random to determine whether or not they pay attention to links with anchor parameters; it's written down somewhere, based on what they're doing with the link. 

I hesitate to make this into a big deal, especially since we're so close (I think) to having this out the door, but letting clients make an arbitrary decision is horrible for interoperability. If I'm using a link header to tell a web browser where a stylesheet is, I should be able to expect that different implementations will behave the same way with regard to it.

On 26/02/2010, at 8:49 PM, Julian Reschke wrote:

> <ref> would point to text that states how to resolve against the context IRI when present.
> 
> And yes, I think consumers can make an almost arbitrary decision about it -- either they ignore the syntax they don't grok, or they process it as specified (where there's really only a single way to process them).
> 
>> This is where I am now:
>> 
> That doesn't work for me, as it makes it sound that somebody needs to do additional work to "specify" it. Who? And what? The only thing that needs to be said is that the anchor param modifies the context, and recipients are allowed to ignore it if the resolved context IRI differs from the original one.
> 
> "The anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI).  If the anchor parameter's value is a relative URI, parsers MUST resolve it as per [RFC3986], Section 5.  Note that any base URI from the body's content is not applied.
> 
> Note that the presence of the anchor parameter affects the context IRI. Thus, consumers either MUST ignore all links that include the anchor parameter, or process it according to its definition above. In the latter case, the resulting context IRI can identify an entirely different resource, in which case consumers can choose to ignore the link."
> 
> (We might have to tune the paragraph for the case where the context resource is anonymous, though)
> 
> > ...
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Feb 2010 21:21:51 +0100

> I think we're saying the same thing here, but your text seems to rely upon the reader to understand that it's underspecified purposefully (the "syntax they don't grok"), whereas I'd like to surface…

Not sure. The thing I didn't like in your proposal is that it sounds 
like somebody (who?) needs to do something special to make the anchor 
parameter work.

> I hesitate to make this into a big deal, especially since we're so close (I think) to having this out the door, but letting clients make an arbitrary decision is horrible for interoperability. If I…

I think we agree that a recipient can't ignore the anchor parameter, 
right? -- and that's what the two UA impls of the Link header currently do.

What the spec needs to say in some way is: "either process the anchor 
parameter, or ignore all links that contain it"

With respect to the stylesheet example: let's assume that I want to add 
an extension to my server that attaches stylesheet links to 404 response 
bodies (where the context resource is anonymous, as described in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.6.1>). 
Let's further assume that the people who did specify "stylesheet" didn't 
think of this use case. How do I get that working later on, then?

Best regards, Julian