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: Thu, 4 Dec 2008 15:04:22 +1100
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Eran Hammer-Lahav <eran@hueniverse.com>
Message-Id: <C6879F03-9776-4960-AA6F-A8DD571B6C1F@mnot.net>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>

Hey Stuart,

I'm inclined to say that they're tied to the representation for a few  

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.
2) links' grounding in entities is already pretty explicit in the  
history of the link header as well as implied by in-document links.
3) a link from a representation to another resource implies an inter- 
resource link, since the representation is (usually) tied to an  
explicit resource.

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.

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  

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/
Received on Thursday, 4 December 2008 04:05:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:38 UTC