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

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 <annevk@opera.com>wrote:

> 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/
>
>