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

> From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com]
> Sent: Wednesday, December 03, 2008 7:20 AM
>
> Hello Mark,
>
> [just dipping into the achive and found this between you and Eran]
>
> > >>   The context of links conveyed in the Link header field is the
> > >>   representation that the header is part of.
> > >
> > > This makes sense since the header is provided in the context of
> > > the representation. However, is there a way to indicate that a
> > > link is persistent across representations and is not
> > > representation- specific? Do 404 and 303 considered representations?
> >
> > *sigh* this is the tricky bit; HTTPbis has at least one open issue
> > on this. I believe the current position is that all messages have
> > entities, and all entities are representations, the trick being that
> > the representation isn't always of the resource which the request
> > was sent to; sometimes it's an "anonymous" representation.
>
> 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.

The current draft is pretty clear that the link is between the conveyed representation of the resource, but what is not clear is to what. Let's assume 'type' is not present in a Link header. This means the on one side of the relationship we have a representation while on the other side we have a resource (as no representation is specified). This gets more complex if we bring 'type' back in.

My current understanding of 'type' is nothing more than a hint. Something to help user-agents better choose the links that serve their needs. Because one resource has no authority to define the content type of another, this 'hint' interpretation is appropriate. But when considering this discussion, 'type' might very well turn out to define the representation of the linked resource the relationship is between.

For example, the response to GET /resource/1:

Content-type: text/html
Link: <http://example.com/resource/2>; rel="next"; type="text/html"

Can mean, this is a link between:

1. /resourse/1 and /resource/2
2. the text/html representation of /resource/1 and (any representation of) /resource/2 3. the text/html representation of /resource/1 and the text/html representation of /resource/2

If /resource/2 does not support the text/html representation, then #3 means a broken link, just as if /resource/2 would return a 404 with no additional useful information.

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

I agree both on simplicity grounds but also because once links are attached to the context of specific representations, it opens up the can of worms above, where the link may or may not be symmetric (one side representation and the other resource). And as demonstrated above, it put the meaning of 'type' in question.

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

I think a) is the right choice and not just for simplicity. The current response has no authority over the link relationships of the other resource identified by the Content-location header.

EHL

Received on Wednesday, 3 December 2008 17:59:50 UTC