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

[ moving follow-up to httpbis ]

Sorry for the delay, Ian. Responses below.

On 31/07/2009, at 10:20 AM, Ian Hickson 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.

I'll take a stab at this in the next rev.


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

How do others feel about this? I'm disinclined to do so unless there's  
considerable value in it. I could see adding a new appendix suggesting  
things that new applications of linking that use this framework,  
however; would that be useful?


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

Is that specific to HTML5? How does HTML5 process rel?


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

It was included because it's in the syntax of RFC2068, but I agree  
that it's not desirable to perpetuate it. How do people feel about  
further removing it (i.e., it will be an extension, not called out  
explicitly in the syntax)?


> 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 think the general consensus is that this is bad practice, but if  
HTML5 wants to define semantics around cardinality, it can do so when  
it defines how that relation is interpreted within the scope of its  
application. I.e., mapping "up up up" to specific behaviours is the  
job of HTML5, not the link framework.

It's worth mentioning here that because HTML5 defines both a syntax  
and what is effectively an application of linking (roughly, "web  
browsing"), it needs to define both the syntax for links and the  
behaviours associated with them.


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

I think I agree; I'll rewrite to point out that there are multiple  
ways of serialising extension links in HTML4 (e.g., as full URIs, with  
@profile, using the RDFa syntax.


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

Ack.


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

Do you have data to back this up? I'm concerned that this would  
disallow internationalisation of title, for example (e.g., you  
couldn't express both an english and a spanish title for a link).


> 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 think that at the very least, it needs to be specified that the  
anchor attribute is not used by default; i.e., specific applications  
of linking need to specify that the anchor attribute is to be used.

I'm also amenable to deprecating or removing it, but would like to  
hear from others about this.


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

I'm not sure what an "external resource link" is, could you please  
remind me?


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

That's a job for HTML5 as an application of the relations, not the  
registry.


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

Again, a job for HTML5.


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

In the IETF, IANA is the mechanism for managing registries like this.


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

If HTML5 chooses to adopt this framework, it would need to:
   1) Define the syntax for serialising and parsing links in HTML5,  
using the terms defined in the draft (see Appendix C), and
   2) Associate concrete behaviours with the general semantics of the  
registered link relations it finds interesting, and
   3) Define how undefined / unrecognised relations are to be handled  
(with a heavy bias towards must-ignore), and
   4) Optionally, define additional registered and/or extension link  
relations.


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


I'd agree that "payment" is ill-defined, but most of the questions you  
ask need to be answered (once again) in the context of a particular  
application of linking, not by the registry.

That said, I think it's worth discussing the relations above to see if  
we can better define them.



--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 19 August 2009 23:56:10 UTC