Subject: [draft-nottingham-http-link-header-06] concerns about Link header

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 31 Aug 2009 12:26:22 +0200

I should probably have expressed my doubts earlier, but I don't really  
have the feeling that implementing the Link header fully per specification  
is really worth all the effort. In fact, dropping the limited support we  
have seems like a more attractive option.

Having a UI for the <link> element never really took of in the decade that  
it existed except for a few special values (which people are bitching  
about on this list; "alternate stylesheet" is one of the few minor success  
stories) and hoping that interest in implementing such a thing will revive  
if we re-introduce the Link header seems misguided. Making the Link header  
more complex than its counterparts by supporting localized titles also  
feels way too much like some nice theoretical idea that might be  
implemented correctly in a few clients but will hardly be used in  
practice. (It also stops it from being semantically equivalent to the HTML  
<link> element, but that is not stated. A bug?)

And while obviously lots of thought went into the specification, the  
primary goal seems to be to getting it to RFC status rather than getting  
it implemented in clients. There are no test cases, almost no checking of  
existing applications, almost no requirements for clients in the draft.

This is also not a feature Web authors are asking for as far as I know.  
(The implementation of the Link header in Opera was more done as a gimmick  
and in retrospect we should probably not have done it.)

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

---

From: Mike Burrows <[email-masked]>
Date: Mon, 31 Aug 2009 11:50:33 +0100

But not all clients are browsers and not all representations are HTML
or XML.  As the basis of a discovery mechanism for scripting clients
and the like, I have found it to be ideal.  Perhaps there isn't a big
need to implement this in browers (TBH that's not for me to say), but
as far as I'm concerned the spec still does have value.  The
alternative is for me just to make up a header syntax of my own -
easily done but wasteful in the long run.  Even the discipline of
turning relationship identifiers into URIs has been of value,
resulting in an self-describing system that is completely transparent
and client-independent.

Mike
[email-masked]
http://positiveincline.com
http://twitter.com/asplake

2009/8/31 Anne van Kesteren <[email-masked]>:
> I should probably have expressed my doubts earlier, but I don't really have
> the feeling that implementing the Link header fully per specification is
> really worth all the effort. In fact, dropping the limited support we have
> seems like a more attractive option.
>
> it existed except for a few special values (which people are bitching about
> on this list; "alternate stylesheet" is one of the few minor success
> more complex than its counterparts by supporting localized titles also feels
> way too much like some nice theoretical idea that might be implemented
> correctly in a few clients but will hardly be used in practice. (It also
> stops it from being semantically equivalent to the HTML <link> element, but
> that is not stated. A bug?)
>
> And while obviously lots of thought went into the specification, the primary
> goal seems to be to getting it to RFC status rather than getting it
> implemented in clients. There are no test cases, almost no checking of
> This is also not a feature Web authors are asking for as far as I know. (The
> implementation of the Link header in Opera was more done as a gimmick and in
> retrospect we should probably not have done it.)
>
>
> --
> Anne van Kesteren

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2009 12:55:34 +0200

Anne van Kesteren wrote:
> have the feeling that implementing the Link header fully per 
> specification is really worth all the effort. In fact, dropping the 
> limited support we have seems like a more attractive option.

Who is "we" in this case? Opera?

> Having a UI for the <link> element never really took of in the decade 
> that it existed except for a few special values (which people are 
> bitching about on this list; "alternate stylesheet" is one of the few 

Bitching?

> minor success stories) and hoping that interest in implementing such a 
> thing will revive if we re-introduce the Link header seems misguided. 
> Making the Link header more complex than its counterparts by supporting 
> localized titles also feels way too much like some nice theoretical idea 
> that might be implemented correctly in a few clients but will hardly be 
> used in practice. (It also stops it from being semantically equivalent 
> to the HTML <link> element, but that is not stated. A bug?)

I don't think it's a bug.

Supporting I18N in the header is something that is not negotiable for an 
IETF spec. I do agree that using multiple instances in the same header 
will be popular, but on the other hand I don't see any reason to forbid it.

> it implemented in clients. There are no test cases, almost no checking 
> of existing applications, almost no requirements for clients in the draft.

What you're criticizing seems to be a matter of specification writing 
style, and it's very clear that there's a big disagreement about that.

 From my point of view, the specification really only needs to describe 
the format. What a client should do when it discovers a specific link 
relation is very hard to prescribe in general, and, in doubt, depends on 
the particular link relation.

BTW, precisely what client requirements are you missing (except for 
instructions how to deal with malformed header instances)?

> (The implementation of the Link header in Opera was more done as a 
> gimmick and in retrospect we should probably not have done it.)

You keep arguing from a browser point of view. There are many HTTP 
resources out there which aren't HTML, but would benefit from the 
ability to expose link relations.

BR, Julian

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 12:52:55 +0200

Anne,

I plan to use HTTP Link: headers with an API I am working on (
http://www.occi-wg.org/) - primarily to advertise alternative
representations, related resources, actions (start, stop, restart),
collections (tasks), etc. and am very happy to have this function for
non-hypertext resources (that is, those which are incapable of expressing
links internally - like binaries).

I also see it as being a relatively lightweight option for semantic web
applications and believe that this was the intention from the early days of
HTTP development. The Link: header as well as the LINK and UNLINK verbs
were, in my opinion, well ahead of their time, and were it not for hypertext
stealing their thunder may well have comprised the "glue" of the web. We do
need glue for non-hypertext formats and I struggle to come up with a better
idea than the great work Mark et al have done already.

You are quite probably right about limited browser support but I don't think
that matters - the clients of the future will necessarily be more
intelligent than those of the past and even if traditional browsers never
implement them fully I can already think of a myriad applications that could
take advantage of them - one off the top of my head is using rel="license"
to categorise the web into zones of reusability.

I also tend to agree with you regarding language support - with everything
else dependent on negotiation I don't see why Link: headers should be any
different. It doesn't help that there will be arbitrary limitations courtesy
proxies, application layer firewalls, clients and client libraries so having
potentially tens of additional titles could well cause breakage. The most
important thing though, in my opinion, is consistency across standards. To
that end a separate document describing generic link relations for
incorporation into other standards could be useful (that is, Atom, HTML &
HTTP would be implementations of that generic standard).

In summary I think the work around web linking (in Atom, HTML & HTTP) is
some of the most exciting development in the space and I would strongly
oppose abandoning it. I'd much rather use something everyone else is using
than having to roll my own.

Sam

On Mon, Aug 31, 2009 at 12:26 PM, Anne van Kesteren <[email-masked]>wrote:

> primary goal seems to be to getting it to RFC status rather than getting it

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 31 Aug 2009 07:24:59 -0400

On Aug 31, 2009, at 6:52 AM, Sam Johnston wrote:
>
> In summary I think the work around web linking (in Atom, HTML &  
> HTTP) is some of the most exciting development in the space and I  
> would strongly oppose abandoning it. I'd much rather use something  
> everyone else is using than having to roll my own.
>

I vehemently agree!

I am predominatly working on creating HTTP-based interfaces in a non  
human driven environment and the Link header has become an integral  
part of that work. Especially since it allows the server to  
communicate links without the need of minting new XML formats. Linking  
information is in my observation often the primary reason for coming  
up with envelopes for the actual intended payload. It helps a lot  
being able to return a pure (not enveloped) document upon GET and  
still be able to send linking information along.

Jan

> Sam
>
> On Mon, Aug 31, 2009 at 12:26 PM, Anne van Kesteren  
> <[email-masked]> wrote:
> I should probably have expressed my doubts earlier, but I don't  
> really have the feeling that implementing the Link header fully per  
> Having a UI for the <link> element never really took of in the  
> decade that it existed except for a few special values (which people  
> are bitching about on this list; "alternate stylesheet" is one of  
> the few minor success stories) and hoping that interest in  
> implementing such a thing will revive if we re-introduce the Link  
> header seems misguided. Making the Link header more complex than its  
> counterparts by supporting localized titles also feels way too much  
> like some nice theoretical idea that might be implemented correctly  
> in a few clients but will hardly be used in practice. (It also stops  
> it from being semantically equivalent to the HTML <link> element,  
> but that is not stated. A bug?)
>
> primary goal seems to be to getting it to RFC status rather than  
> getting it implemented in clients. There are no test cases, almost  
> no checking of existing applications, almost no requirements for  
> clients in the draft.
>
> This is also not a feature Web authors are asking for as far as I  
> know. (The implementation of the Link header in Opera was more done  
> as a gimmick and in retrospect we should probably not have done it.)
>
>
> -- 
> Anne van Kesteren

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 11:55:52 +0100

On Mon, Aug 31, 2009 at 11:50:33AM +0100, Mike Burrows wrote:
> and the like, I have found it to be ideal.

Firefox prefetching uses it:

  https://developer.mozilla.org/en/Link_prefetching_FAQ

The Semantic Web crowd promotes it:

  http://esw.w3.org/topic/LinkHeader

TimBL has recommended this to me as a way of linking RDF to resources.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

---

From: Michael Hausenblas <[email-masked]>
Date: Mon, 31 Aug 2009 12:31:52 +0100

> than having to roll my own.

+1 

IMHO an area which is neglected and should get more attention. You're
invited to have a look at a technical report we've recently published [1]
and a service [2] we're building to support the discovery area (in early
alpha, so please bear with us ;)

Cheers,
      Michael

[1] http://linkeddata.deri.ie/tr/2009-discovery
[2] http://uldis.deri.ie/

-- 
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

> From: Sam Johnston <[email-masked]>
> Date: Mon, 31 Aug 2009 12:52:55 +0200
> To: Anne van Kesteren <[email-masked]>
> Cc: HTTP Working Group <[email-masked]>
> Subject: Re: [draft-nottingham-http-link-header-06] concerns about Link header
> Resent-From: <[email-masked]>
> Resent-Date: Mon, 31 Aug 2009 10:58:02 +0000
> 
> Anne,
>

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 14:09:18 +0200

> TimBL has recommended this to me as a way of linking RDF to resources.

...or to skip RDF and link resources directly to one another.

Another production application I somehow managed to forget before is
rel=shortlink <http://purl.org/net/shortlink>, which allows a webmaster to
mint their own short links (e.g. for space constrained applications like
microblogging and SMS or pretty much anywhere humans need to transcribe URLs
- TV, radio and print). Clients (e.g. Twitter applications) can then pick
these up with HTTP HEAD requests which saves downloading and parsing the
entire HTML page. Not only is linkrot all but eliminated but the links are
higher quality/less opaque (eg http://microsoft.com/win7 rather than
http://tinyurl.com/decafbad) and therefore more secure, plus as everyone's
using the same one things like visited link colouring still works.

With wordpress.com jumping on board (and wordpress.org soon to follow suit)
there's already around 115m pages advertising these links.

Sam

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 13:19:51 +0100

On Mon, Aug 31, 2009 at 02:09:18PM +0200, Sam Johnston wrote:
> Not only is linkrot all but eliminated but the links are higher quality/less
> opaque (eg http://microsoft.com/win7 rather than http://tinyurl.com/decafbad)
> and therefore more secure, plus as everyone's using the same one things like
> visited link colouring still works.

These "short" links increase link rot. Now instead of relying on a single domain
name, and a single host, you are relying on two of each. And as these linking
services go off-line, entire swaths of the Web break silently.

Best,

---

From: Sam Johnston <[email-masked]>
Date: Mon, 31 Aug 2009 14:46:51 +0200

> services go off-line, entire swaths of the Web break silently.

This is OT but worth clarifying nonetheless.

Assuming we agree there's a need for short links[1] then I recommend people
use their existing [generally already as short as possible] domain name
rather than some other domain that's likely to be forgotten, expire, break,
etc. Using the same domain is not only more transparent for users (consider
wordpress.com vs wp.me) but can be significantly more performant. URL
shorteners currently add hundreds of milliseconds to requests higher level
proposals like Adjix<http://www.scripting.com/stories/2009/08/19/howToFixUrlshorteners.html>are
almost certainly even more expensive. Rather than having to
recursively
resolve two domains (possibly including CNAMEs), complete two TCP handshakes
and then conduct two separate HTTP requests, the redirect overhead can be
reduced to negligent levels by reusing a single HTTP connection.

Those sites that still choose to use a "domain hack" (like
wordpress.com->wp.me, techcrunch.com->tcrn.ch) should advertise both and let
clients choose - they can go for the shortest, most descriptive (longest) or
most performant (same domain).

As for linking services going offline, it's much the same as the situation
with third-party DNS services <http://cr.yp.to/djbdns/third-party.html> - if
the resource is down there's no point having the pointers to it. The best
situation is where they are colocated, for example being generated by a CMS
[plugin] (e.g. Drupal, Wordpress) - that way anything which takes out the
short links will also take out the target content and when the content is
taken offline the links are cleaned up too.

I've thought about this problem for some time now and have been unable to
come up with a better option, but if you can then I'm all ears as it's not
too late to change tack. If we don't do something then others
will<http://www.mnot.net/blog/2009/04/14/rev_canonical_bad>
.

Sam

1. Even if Twitter were rich text and thus hid the links we'd still have SMS
and physical applications to think about like radio, print and TV
advertising. Conversely, canonical links want to be as descriptive as
possible so as to contain lots of SEO juice. That is, the requirements are
diametrically opposed.

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 11:42:21 +0100

> This is also not a feature Web authors are asking for as far as I know.

I am a Web author, and I edit all of my HTML documents by hand.

I use this header for CSS on my site:

  http://tumbolia.org/

Doing so eliminated a lot of boilerplate for me.

It works in Firefox (my browser) and Opera, but not Safari.

There is a bug open to fix that issue:

  https://bugs.webkit.org/show_bug.cgi?id=20018

I urge people to vote on it.

Best,

---

From: Nicolas Alvarez <[email-masked]>
Date: Mon, 31 Aug 2009 16:07:48 -0300

> <link> element, but that is not stated. A bug?)

I *badly* want browser UI for 'next' and 'previous' and 'up', and preferably
also keyboard shortcuts.

---

From: Noah Slater <[email-masked]>
Date: Mon, 31 Aug 2009 20:38:51 +0100

> I *badly* want browser UI for 'next' and 'previous' and 'up', and preferably

Check out:

  Link Widgets 1.6.6

  https://addons.mozilla.org/en-US/firefox/addon/2933

Best,