Input to IETF HTTP Link Headers

I am delighted that the IETF HTTP WG is to discuss Link headers. The W3C POWDER working group that I chair is just getting going so I cannot speak on behalf of the group, only give my personal views. That said, POWDER has a history! Under the preceding WCL-XG we discussed the issue and it's also been raised in the Mobile Web Best Practices Group [MWBP] in which I also participate.

Mark Nottingham's document drafted last year [MNOTT] does, I think, cover just about everything I believe POWDER will need however I will put that to one side and set out the basic use case.

POWDER, the Protocol for Web Description Resources, is designed to allow an identifiable entity to describe a group of resources. In the Mobile Web Best Practices case, we want to be able to say that "ACME testing says everything on example.org is mobileOK." In my own organization's case, we want content providers to be able to describe their content using the ICRA vocabulary [VOCAB] (which covers child protection issues) and then for us to able to publish data that says that, having reviewed the data, we stand by that self-description. There are many more use cases, such as trustmarks, privacy policies and licensing but the ICRA and mobileOK cases will suffice for this discussion.

The system used by ICRA today [ICRA] is an early prototype of where I expect POWDER to end up. An RDF instance carries the descriptive data and "labelled resources" link to it thus:

We also recommend usage of the HTTP version of this:

Link: </labels.rdf#label_1>; /="/"; rel="meta" type="application/rdf+xml"; title="ICRA labels";

Recommending the HTTP Link header is born of practicality and expediency. First of all, of course, it allows non-HTML resources to carry the link, but there's more to it than this. Web content is typically produced by multiple staff in multiple locations (Yahoo! is a classic example of this of course). Using the HTML Link tag puts the burden on the content production staff or at least those responsible for maintaining the templates. This is a relatively dynamic environment where things like link tags that don't have an immediate effect on the look and feel of the page are easily added one week and deleted the next. Including the links through server configuration will generally prove more stable and reliable.

You'll notice that we use the "meta" relationship type but this is not ideal (it's not listed, for instance, in the HTML 4 spec). What we really want is to be able to write:

Link: <http://example.org/labels.rdf>; rel="POWDER"

(supplementary attributes omitted for clarity)

Which, I understand, is where you see the profile header being useful as that could link to a document that defined what the relationship type "POWDER" means. Good!

Question: The documentation surrounding metadata profiles [PROFILE] discusses the HTML meta element, not link relationship types. It appears therefore that the use of the putative Profile HTTP header to point to a resource that defines link relationship types will lead to a different meaning of 'profile' depending whether it is included in the head element of an HTML document or in an HTTP header. This looks like being a significant problem (or it means I've misunderstood something?).

Section 6.12 of the HTML4 spec, which lists the link types, makes it clear that the rel attribute of a link element takes a whitespace separated list of relationship types. This is a potentially useful feature for POWDER. To return to the earlier example, a user agent interested in whether resources are mobileOK may not be interested in any ICRA descriptors (or vice versa). Therefore, as an aid to efficiency, some members of the various working groups mentioned above have argued that the link relationship might look like this:

Link: <http://example.org/labels.rdf>; rel="POWDER ICRA mobileOK"

In other words, the link relationship would not only declare that the linked item is a Description Resource but that it contained descriptions from the ICRA and mobileOK namespaces. The argument against this is that if a content provider sets up their Description Resources with, say, ICRA in mind, and later decides to add in mobileOK descriptors, they then have to go back and edit the HTTP headers. Whilst this may be trivial for some content providers, for others it won't be.

Given that the rel attribute is already defined as taking a whitespace separated list, this is a minor point in terms of the development of the putative Profile header and re-emphasis on the Link header itself, however, I hope it gives some useful extra information.

Following on from that, I can see that the proposed template header might be helpful here. For example, a content provider might include this template header:

Link-Template: <http://www.example.org/DR/{type}.rdf>; rel="POWDER"

A user agent interested in Description Resources would supply the 'type' variable such as, in this example, ICRA or mobileOK, and thus be able to retrieve the descriptions which it is able to process. Whilst that looks like an excellent way to handle both efficiency and extensibility, I think Description Resources will have to have proved themselves in a static environment before such relatively advanced user agents are developed.

Phil Archer, 9 March 2007

POWDER: http://www.w3.org/2007/powder/
WCL-XG: http://www.w3.org/2005/Incubator/wcl/
MWBP: http://www.w3.org/2005/MWI/BPWG/
MNOTT: http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt
VOCAB: http://www.icra.org/vocabulary/
ICRA: http://www.icra.org/systemspecification/
HTML 4: http://www.w3.org/TR/html4/types.html#type-links
PROFILE: http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3