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.

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:20:04 UTC