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: Ian Hickson <ian@hixie.ch>
Date: Wed, 30 Sep 2009 02:33:30 +0000 (UTC)
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.62.0909300216450.25383@hixie.dreamhostps.com>
On Fri, 25 Sep 2009, Mark Nottingham wrote:
> > > 
> > > OK. The point is that some XML+CSS spec needs to define this 
> > > behaviour.
> > 
> > I don't see why an XML spec or a CSS spec or even an XML+CSS spec 
> > would define the behaviour of an HTTP header. Surely the spec for the 
> > HTTP header would be the one to define the behaviour of the HTTP 
> > header.
> It's not defining the relation of an HTTP header, Ian; it's defining the 
> semantics of a link relation when used with XML and CSS.

I do not consider this to be a satisfactory resolution to my feedback.

You are effectively introducing a new feature; how that feature works 
needs to be specified.

> > People will and do mint keywords without coordinating with us or 
> > asking for our review.
> > 
> > Our choice is just whether we want them to register these keywords 
> > first, or whether we want them to not register them first.
> > 
> > Whether they register them will depend on whether we make it easy or 
> > not.
> > 
> > I'm not making any judgements about whether this behaviour is 
> > desireable, good, bad, or the right way to do things. It's just how 
> > things are. Ignoring it is just going to make the registry irrelevant 
> > in practice.
> Of course they will do this; the draft already takes the stance that 
> unrecognised (i.e., not in the registry, or not implemented by the app) 
> relation types have purely localised meaning; i.e., they may mean 
> something in a particular context, but all bets are off beyond that.

This means that the main goal of having a registry -- namely to avoid 
conflicts when "purely localised" relations become more widely used and 
two different unrelated communities end up having used the same term -- is 
not met by this proposal. I do not consider this satisfactory.

> > > When presenting links to users, agents SHOULD use the most 
> > > appropriate "title*" value, according to user preferences. If an 
> > > appropriate "title*" value cannot be found, the "title" parameter's 
> > > value, if available, can be used.
> > > 
> > > Does this work?
> > 
> > Seems reasonable, though I am still skeptical as to the use of the 
> > title* feature in practice. It seems better to me to just have one 
> > title attribute, in one language, and to upgrade HTTP to support UTF-8 
> > in headers.
> That's already been discussed extensively, and that's not the direction 
> things are going in (certainly for pre-existing headers like Link).

Fair enough. Is there a test suite I can look at or some implementations 
of this feature so I can see how it works in practice?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 30 September 2009 02:25:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC