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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 31 Aug 2009 12:55:34 +0200
Message-ID: <4A9BAC26.6070407@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Anne van Kesteren 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.

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.

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

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)?

> 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.)

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
Received on Monday, 31 August 2009 10:57:34 GMT

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