W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

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

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Thu, 4 Dec 2008 16:44:10 +0000
To: Eran Hammer-Lahav <eran@hueniverse.com>, Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <233101CD2D78D64E8C6691E90030E5C8245CDEB4D5@GVW1120EXC.americas.hpqcorp.net>

Hello Eran,

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: 04 December 2008 16:19
> To: Williams, Stuart (HP Labs, Bristol); Mark Nottingham
> Cc: ietf-http-wg@w3.org
> Subject: RE: Feedback for draft-nottingham-http-link-header-03
>
> 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.

If you take the view, which I think is the correct view - and I think that you do to, that the links being claimed at least in a response, are between the requested resource and the resource targetted by the link, the question of which representation is taken as "canonicial" or in some sense 'supreme' becomes immaterial.

[BTW: At a given moment all available representations of a given resource should at least be consistent with each other. It is not necessary that they convey the same information content - but the should be a coherent set of representations of the same resource - in particular the referents associated with any fragIDs that 'address' into the resource should be consistent so, for eg in RDFa the same 'anchor' should not resolve to being an HTML element and a foaf:Person [I have seen such written] see: http://www.w3.org/TR/webarch/#frag-coneg]

> Of course there is an easy implementation solution to this,
> just replicate the Link headers across all possible
> representations.

Hmmm I'd express that as "...replicate the Link headers across all variant resources." though I'd also acknowledge that there may be cases where each variant requires different links.

> I would even bet that many server
> implementations are not even going to bother making it easy
> to customize the headers per representation, and simply
> associate it with the resource. And the same goes from the
> application side, specifying the Link header consistency for
> their rel type is required across representation.
>
> EHL

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Thursday, 4 December 2008 16:51:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT