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

Hi Eran,

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?

Concretely, if the UA were to actually access the link found in a Link 
header, but provide an Accept header that was in conflict with the 
content type of the representation found at the URI provided in the Link 
header it got, the server could decide (for example) to return an HTTP 
300 status with a list of URIs indicating alternative representations, 
even providing a redirect to the "canonical" URI.

- johnk

> 
> 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
>

Received on Thursday, 4 December 2008 16:52:16 UTC