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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 5 Dec 2008 11:22:42 +1100
Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <FB309390-C1C1-449E-B381-021E6D429D82@mnot.net>
To: Eran Hammer-Lahav <eran@hueniverse.com>

If the response Varies, yes; just as the response format can vary from  
representation to representation, so can the headers (e.g., ETag).

In the common case, I suspect that the links wouldn't vary, unless  
they're to specific formats; e.g., if the HTML response returns links  
to more HTML resources, while the XML response returns links to more  
XML resources, it makes sense for this to be in the link headers  
(assuming you don't want to use server-driven content negotiation).

Cheers,


On 05/12/2008, at 3:19 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.
>
> Of course there is an easy implementation solution to this, just  
> replicate the Link headers across all possible representations. 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
>
>
>
>> -----Original Message-----
>> From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com]
>> Sent: Thursday, December 04, 2008 3:50 AM
>> To: Mark Nottingham
>> Cc: ietf-http-wg@w3.org; Eran Hammer-Lahav
>> Subject: RE: Feedback for draft-nottingham-http-link-header-03
>>
>> Hello Mark,
>>
>>> -----Original Message-----
>>> From: Mark Nottingham [mailto:mnot@mnot.net]
>>> Sent: 04 December 2008 04:04
>>> To: Williams, Stuart (HP Labs, Bristol)
>>> Cc: ietf-http-wg@w3.org; Eran Hammer-Lahav
>>> Subject: Re: Feedback for draft-nottingham-http-link-header-03
>>>
>>> Hey Stuart,
>>>
>>> I'm inclined to say that they're tied to the representation for a  
>>> few
>>> reasons;
>>
>>
>>> 1) a Link header can potentially be included in a request as well;
>>> e.g., on a POST or PUT request body. In such a case, there is at  
>>> best
>>> an ephemeral/virtual resource.
>>
>> I guess I find that surprising. Can you explain the intended  
>> semantics
>> including a link header in a PUT/POST request. eg. is it saying  
>> please
>> establish a link between the requested resource (or a resource  
>> created
>> in response to a POST) and the link target? ie. is it intended as a  
>> way
>> to establish link relations that are subsequently reported in GET/ 
>> HEAD
>> responses?
>>
>> If that's the case I would still view that as a relation established
>> between requested and targetted resource (though in the POST case I  
>> can
>> see a case for the relation being established with the resource
>> referenced by any Location: header rather than the requested  
>> resource).
>>
>>> 2) links' grounding in entities is already pretty explicit in the
>>> history of the link header as well as implied by in-document links.
>>
>> This is the tricky use of the word 'document'. Document is one of  
>> those
>> words that can pun between a resource like thing or a representation
>> like thing.
>>
>> Links are reported in document representations - because the document
>> resource which they are a representation of is so linked... but the
>> link is between resources, even 'in-document' - that just happens  
>> to be
>> manifest in the conveyed representations.
>>
>>> 3) a link from a representation to another resource implies an  
>>> inter-
>>> resource link, since the representation is (usually) tied to an
>>> explicit resource.
>>
>> Eggs and chickens... on the whole I think that we agree. However, can
>> you explain to me how I make reference to a representation - the one
>> that I got this morning when I accessed the W3C web site? How do I do
>> that conveniently with a URI?
>>
>>> Think about it from how in-document links work; if a response
>> contains
>>> a <link>, the link is resolved using the document's URI -- which  
>>> does
>>> identify the resource -- as the base URI for resolving the target,  
>>> as
>>> well as the context of the link. The representation *isn't*
>> ephemeral,
>>> it's a representation of an identified resource.
>>
>> There is a type/token thing going on here. We are not clear whether  
>> by
>> representation we are speaking of (roughly) a particular message that
>> crossed a particular interface at a particular time; or whether we  
>> are
>> talking about a class of messages that all convey the same literal
>> sequence of bits.
>>
>> Regardless, even with the (latter) coarser grained notion of
>> representation - the representation is a view of the resources  
>> state -
>> it is not the resource; it may not expose all the links that there
>> resource may have; and it may change over time. Most crucially AFAIK
>> there is no systemic way of making reference to one using a URI.
>>
>>> So I don't think we're disagreeing at heart; it's just that the
>>> relationship between the representation and the resource is already
>>> defined by the Web architecture, and shouldn't be re-specified by
>>> links...
>>
>> I am not suggesting that it should. I'm suggesting that the Link  
>> header
>> be specified in a way that is consistent with web architecture.
>>
>> http://www.w3.org/TR/webarch
>> "Link
>> A relationship between two resources when one resource  
>> (representation)
>> refers to the other resource by means of a URI. "
>>
>> Though I would concede that we are perilously close to dancing on the
>> head of a pin.
>>
>> Stuart
>> --
>>>
>>>
>>> On 04/12/2008, at 2:20 AM, Williams, Stuart (HP Labs, Bristol)  
>>> wrote:
>>>>
>>>> Oh dear... I think we need to be clear about the whether the
>>>> relations being conveyed in Link: headers are intended to hold
>>>> between resources or between the conveyed representation and
>>>> whatever the target URI refers to.
>>>>
>>>> Personnally, my hope is that the relations are regarded as holding
>>>> between the resources that are referenced by URIs (as opposed to
>> one
>>>> party to the relation being a more ephemeral representation or
>>>> message being conveyed).
>>>>
>>>> Of course the question is what resource supplies the context,
>>>> particularly in the case of a response that carries a "Content-
>>>> Location:" header that carries a different URI from that in the
>>>> request.
>>>>
>>>> It seems to me that candidate choices for the context resource are:
>>>>
>>>> a) the resource referenced in the request line of the corresponding
>>>> HTTP request.
>>>> b) the resource referenced in a Content-Location: header returned
>> in
>>>> the same response.
>>>>
>>>> are there any other candidates?
>>>>
>>>> Does one take a) as the default and allow b) if present to override
>>>> a), or simply stick with the original request URI.
>>>>
>>>> Simplicity suggests just a) and that if you want to find out about
>>>> links associated with the resource reference by a "Content-
>>>> Location:" then you go ask there.
>>>>
>>>> Regards
>>>>
>>>> Stuart
>>>> --
>>>> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,
>>>> Berks RG12 1HN
>>>> Registered No: 690597 England
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Mark Nottingham     http://www.mnot.net/
>>
>> --
>> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
>> Berks
>> RG12 1HN
>> Registered No: 690597 England


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 5 December 2008 00:23:25 GMT

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