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

From: Mark Nottingham <[email-masked]>
Date: Fri, 31 Jul 2009 20:20:06 +0200

Hi Ian,

Thanks for the feedback. I'm on the road at the moment, but will  
respond when I get a chance.

Cheers

Mark Nottingham

On 31/07/2009, at 2:20 AM, Ian Hickson <[email-masked]> wrote:

>
> 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.   `._.-(,_..'-- 
> (,_..'`-.;.'

---

From: Julian Reschke <[email-masked]>
Date: Sun, 02 Aug 2009 09:18:42 +0200

Ian Hickson wrote:
> ...
> 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.
> ...

Could you please elaborate what the "right" effect is, and how current 
implementations fail for that?

It appears to me that anchor is not relevant for every single link 
relation, but that doesn't mean it's not useful at all.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 02 Aug 2009 12:47:06 +0200

Ian Hickson wrote:
> Well unless I'm mistaken, if we have a resource A that has:
> 
>    Link: <B>; rel=stylesheet; anchor=C
> 
> ...then that means we have a link:
> 
>    C - stylesheet - B
> 
> ...which means that applying the style sheet to A would be wrong. Yet that 
> is what UAs that support Link: would presumably do.

Of the five UAs I checked, two seem to implement the Link header. Both 
fail to consider the anchor.

To make Link headers useful in processing by HTML user agents, lots of 
additional implementation work is needed anyway; so I don't see this as 
a big problem.

That being said, it probably would be good if the spec gave an example 
that anchor can be more than a fragment identifier, and thus recipients 
need to handle it -- it's not optional.

> I don't see how it can't be relevant... if the link relation is between 
> two resources, then acting as if it was a relationship between others 
> seems wrong.

Right; it *is* relevant if it's more than a fragment identifier, and it 
would be good if the spec stated that clearly.

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Sun, 2 Aug 2009 09:04:41 +0000 (UTC)

On Sun, 2 Aug 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > 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.
> 

   C - stylesheet - B

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