RE: Feedback for draft-nottingham-http-link-header-03

> -----Original Message-----
> From: John Kemp [mailto:john@jkemp.net]
> Sent: Thursday, December 04, 2008 8:40 AM
>
> Eran Hammer-Lahav wrote:
> > My original question still remains unanswered after this dance.
> > Should a UA expect a different set of Link headers returned for
> > GET/HEAD based on the requested Accept header or response
> > Content-type header? Or can it assume that no matter what
> > representation it *got*, the Link headers are going to remain the
> > same. From a discovery standpoint, the former is problematic as there
> > is no way of telling which representation is the "canonical" one for
> > the purpose of establishing links.
>
> Can you explain why is this so problematic for the UA?

Just problematic (without the 'so') :-). It is really application specific (and I have one in mind). If I'm building an application framework that defines links as between resources regardless of representations, using a GET/HEAD to retrieve such relationships is muddled by the existence of a representation context that the UA knows/cares little about. In addition, some UA will impose some representation viewpoint (such as adding an Accept header with some default value) that can skew the value of the returned links without the ability of the application to tell that the links information is different from other representations.

OpenID is one example where today it uses the 'X-XRDS-Location' header to allow using a URI with a valid HTML representation as a user identifier for signing in to sites. So the URI is used for two different things (getting a representation and as a unique identifier used in form entry). The 'X-XRDS-Location' ties the two together by allowing the identity information about the URI to reside elsewhere (in the XRDS document identified by the custom header).

If OpenID is to move to use the more standard Link header the current:

X-XRDS-Location: http://example.com/openid.xrds

Will turn into:

Link: <http://example.com/openid.xrds>; rel="describedby"; type="application/xrds+xml"

But while 'X-XRDS-Location' is a 'resource --> resource' link, the same may or may not be true for Link. What we need is crisp clarity so that applications such as OpenID will know how to address that, by for example, requiring that the Link header above be placed (identically) on all representation of the resource used as an identity identifier.

EHL

Ps. And yes, I am open to discussion about whether the OpenID dual use of a URI (say a blog and an identity identified) is consistent with web architecture. Not promising that such discussion will lead to anything... :-)

Received on Thursday, 4 December 2008 17:52:01 UTC