W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 30 Aug 2009 18:48:00 +0200
Message-ID: <4A9AAD40.50105@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>, Ian Hickson <ian@hixie.ch>, Mark Nottingham <mnot@mnot.net>, Eran Hammer-Lahav <eran@hueniverse.com>, Sam Johnston <samj@samj.net>, HTTP Working Group <ietf-http-wg@w3.org>
Noah Slater wrote:
> On Sun, Aug 30, 2009 at 12:00:51PM +0200, Julian Reschke wrote:
>> Does Mozilla support the Link header for any relation besides stylesheet
> 
> Yes, the following get you feed discovery:
> 
>    @rel='alternate' @type='application/atom+xml'
> 
>    @rel='alternate' @type='application/rss+xml'

But that's the link *tag*, not the link header. I just tried, and 
Firefox 3.5 does not appear to check the link header for that.

> And the Mozilla suite browser natively supports everything from "last", "prev",
> "next", "first", "up", "copyright", "about", "search", a bunch of other de-facto
> @rel values, and all the ones found here:
> 
>   http://www.w3.org/TR/html401/types.html#type-links

But, as far as I can tell, only the link *tag*, not the header.

> Firefox does not support this natively, but there is a plugin to add it.

Same here.

>>> The main advantage of rel="up up up" rather than rel="up3" is that for
>>> UAs that only need to know that the link is an "up" and don't care
>>> about how far "up" it goes, the keyword automatically works -- you
>>> don't have to do rel="up up3". Also, it means that we don't have to
>>> register an infinite number of keywords for all possible depths.
>> Are there UAs that already support "up up" the way you defined it? How
>> did that extension make it into the spec anyway?
> 
> I needed to express the "up" relation in my HTML and Atom documents, and I took
> a look at the HTML5 spec to see what the recommendation was. I wasn't planning
> on using HTML5, but I figured that it might be a good place to check anyway.
> 
> After thinking about it for a while, I decided that there was no sufficient
> reason to use more than a single "up" value. My reasoning is that URIs already
> provide a mechanism for UAs to determine the spacial position of the current
> resource in relation to the one specified via a link element.
> 
> Resource URI:
> 
>   http://example.org/dir-a/dir-b/doc-b
> 
> Links elements:
> 
>   <link rel="up" href="/">
> 
>   <link rel="up" href="/dir-a/">
> 
>   <link rel="up" href="/dir-a/dir-b/">
> 
> The hierarchical position of each link can be found by parsing the URI.

Well, that won't always be the case. In the case where the URL hierarchy 
happens to be the actual hierarchy, you really don't need the link 
relation (as demonstrated by the Firefox addon).

BR, Julian
Received on Sunday, 30 August 2009 16:48:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT