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

From: Ian Hickson <[email-masked]>
Date: Fri, 31 Jul 2009 00:20:10 +0000 (UTC)

In general, I don't really understand what problem this draft is trying to 
solve. A clearer statement in the abstract or introduction explaining 
_why_ a common registry is a good thing would be very useful.

It might also be worth considering separating the Link: header and the 
registry into two different specifications. This would also help clarify 
how a specification should refer to the registry.

Comparing relation types case-sensitively (e.g. as in 4.2 Extension 
Relation Types) is incompatible with HTML's processing of rel=""; I would 
like to request that all relations always be case-insensitive.

The Link: header has a "rev" attribute. I would recommend dropping it for 
consistency with HTML5; we discovered in examining typical usage that 
people generally didn't understand how to use rev="", and it is redundant 
with rel="" anyway. If it is kept, then please define how it works. 
Allowing something but leaving it undefined is the worst of both worlds. 
(The ideal would be to define how it works but not allow it, IMHO.)

The link relations should better define how to handle interactions between 
multiple link types, so that alternate stylesheet can be well-defined, 
and so that we can define rel="up up up" as in HTML5.

I recommend dropping the entire bit about profile="" -- while it sounds 
like the right thing to do, in practice almost nobody uses profile="", and 
the attribute has been dropped in HTML5. This is a lot of complexity 
without a particularly compelling use case as far as I can tell.

The spec should clearly say which takes preference if both title= and 
title*= are given. Also, the spec should clearly say which takes 
preference if multiple title=, type=, etc, attributes are given.

I think for the best compatibility with legacy implementations, the spec 
should say that there must only be one occurance of each attribute, and 
that multiple link types in one Link: header should be listed in one 
rel="" attribute. (That is, only allow rel="a b", not rel=a;rel=b.)

Unless there are really strong use cases, I think that the anchor= 
attribute should be dropped. In practice, implementations today ignore 
that attribute, which would mean that, e.g., a rel=stylesheet;anchor=a 
link would fail to have the "right" effect. If it is kept, then the right 
behaviour for how this should integrate with style sheet linking should be 
defined in great detail.

I would like to request that each link type be defined as either being a 
hyperlink or an external resource link, as defined in HTML5, and that 
this be added as one of the things that must be defined in the registry.

Similarly, the registry should define whether or not link relations are 
allowed at the document level (<link rel>, Link:) and at the phrasing 
level (<a rel>, <area rel>). Some types in HTML5 only apply to one or the 
other.

Ideally, I would like the Link: header section to more clearly define how 
some of the keywords defined in the spec should actually be used. For 
example, how should the rel=stylesheet keyword affect the CSSOM? Where do 
resources imported in this way fall in the CSS cascade? How should it 
affect documents with MIME types like text/plain? Do rel=icon links 
interact with those specified in the document? If so, where should they be 
considered as falling in terms of tree order?

I would like to request that the registration mechanism be made 
significantly simpler than the one described in the spec. For example, a 
simple mechanism could be just to edit a wiki listing all the extensions.

I would like to request some guidance on what HTML5 would have to do to be 
compatible with this draft, and what benefits would come from it. There 
are clear benefits to the Link: header section, assuming that how it fits 
into the general Web platform is defined (as requested above). But how 
does the registry fit into the RelExtensions registry for HTML5? How 
should they interact?

The "up", "first", "last", and "payment" types are woefully underdefined. 
What is the expected UA behaviour when discovering a link with 
rel=payment? What are the authoring requirements? What are the 
implementation requirements?

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'