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

From: "Williams, Stuart (HP Labs, Bristol)" <[email-masked]>
Date: Wed, 3 Dec 2008 15:20:26 +0000

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.

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Dec 2008 15:04:22 +1100

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

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

--
Mark Nottingham     http://www.mnot.net/

---

From: "Williams, Stuart (HP Labs, Bristol)" <[email-masked]>
Date: Thu, 4 Dec 2008 11:50:05 +0000

Hello Mark,

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: 04 December 2008 04:04
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: [email-masked]; Eran Hammer-Lahav
> Subject: Re: Feedback for draft-nottingham-http-link-header-03
>
> Hey Stuart,
>

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

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

> resource link, since the representation is (usually) tied to an

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?

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

> defined by the Web architecture, and shouldn't be re-specified by

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Dec 2008 09:19:14 -0700

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

> From: Williams, Stuart (HP Labs, Bristol) [mailto:[email-masked]]
> Sent: Thursday, December 04, 2008 3:50 AM
> To: Mark Nottingham
> Subject: RE: Feedback for draft-nottingham-http-link-header-03
>
> Hello Mark,
>
> 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).
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> A relationship between two resources when one resource (representation)
> refers to the other resource by means of a URI. "
>
> > > b) the resource referenced in a Content-Location: header returned
> in
> > > the same response.
> > >

---

From: "Williams, Stuart (HP Labs, Bristol)" <[email-masked]>
Date: Thu, 4 Dec 2008 16:44:10 +0000

Hello Eran,

> From: Eran Hammer-Lahav [mailto:[email-masked]]
> Sent: 04 December 2008 16:19
> To: Williams, Stuart (HP Labs, Bristol); Mark Nottingham
> Cc: [email-masked]
> 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.

If you take the view, which I think is the correct view - and I think that you do to, that the links being claimed at least in a response, are between the requested resource and the resource targetted by the link, the question of which representation is taken as "canonicial" or in some sense 'supreme' becomes immaterial.

[BTW: At a given moment all available representations of a given resource should at least be consistent with each other. It is not necessary that they convey the same information content - but the should be a coherent set of representations of the same resource - in particular the referents associated with any fragIDs that 'address' into the resource should be consistent so, for eg in RDFa the same 'anchor' should not resolve to being an HTML element and a foaf:Person [I have seen such written] see: http://www.w3.org/TR/webarch/#frag-coneg]

> Of course there is an easy implementation solution to this,
> just replicate the Link headers across all possible
> representations.

Hmmm I'd express that as "...replicate the Link headers across all variant resources." though I'd also acknowledge that there may be cases where each variant requires different links.

> 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

Stuart

---

From: John Kemp <[email-masked]>
Date: Thu, 04 Dec 2008 11:40:27 -0500

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:[email-masked]] Sent: Thursday, December 04, 2008 3:50
>> AM To: Mark Nottingham Cc: [email-masked]; Eran Hammer-Lahav 
>>> -----Original Message----- From: Mark Nottingham
>>> [mailto:[email-masked]] Sent: 04 December 2008 04:04 To: Williams,
>>> Stuart (HP Labs, Bristol) Cc: [email-masked]; 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).
>> 
>> 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?
>> 
>>> 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,
>> 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.
>> 
>> 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.
>> 
>>> 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. "
>> 
>> Stuart --
>>>> Personnally, my hope is that the relations are regarded as
>>>> holding between the resources that are referenced by URIs (as
>>>> opposed to
>> one
>>>>  Location:" header that carries a different URI from that in
>>>> the request.
>>>> 
>>>> 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.
>>>> 
>>>> 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
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Dec 2008 10:31:31 -0700

> Sent: Thursday, December 04, 2008 8:44 AM
>
> If you take the view, which I think is the correct view - and I think
> that you do to, that the links being claimed at least in a response,
> are between the requested resource and the resource targetted by the
> link, the question of which representation is taken as "canonicial" or
> in some sense 'supreme' becomes immaterial.

[It takes a while to get used to my style, but while I usually talk in absolutes, there are very few things I have strong opinions on (this is not one of them). I'm also really new to web architecture (I served a 10 year term in investment banking before I escaped to a web job).]

The 'canonical' question doesn't apply if you take the view that link is between resources and not representations. But it becomes an implementation concern when building an application that defines links to be between resources, and the Link header is not fully compatible with that. Resource discovery (XRDS, POWDER, OpenID, etc.) depends on links having a resource and not representation context. But again, there are easy implementation-based solutions if the spec goes the representation way.

I prefer to define links as between resources regardless of their representation mostly for the following reasons:

1. I think links should be symmetric and 'representation --> resource' isn't symmetric. 'resource --> resource' is nice and clean.
2. If a 'rel' link is defined as 'representation --> resource' that forces 'rev' to be 'resource --> representation'. It means that 'B --(rev)--> A' has nothing to do with 'A --(rel)--> B' because each is between different objects (resource / representation).
3. The other way to accomplish symmetry is 'representation --> representation' which has been rejected here before. That would shift the meaning of 'type' from a hint to an actual part of the relationship context (needed to define the representation of the linked resource in context for the link).

There are clear implications for defining link as 'representation --> resource' vs. 'resource --> resource'. One of them is the impact of the definition of the 'rel/rev' relationship. All I am asking for is clarity.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Dec 2008 10:51:15 -0700

> From: John Kemp [mailto:[email-masked]]
> Sent: Thursday, December 04, 2008 8:40 AM
>
> Eran Hammer-Lahav wrote:

Just problematic (without the 'so') :-). It is really application specific (and I have one in mind). If I'm building an application framework that defines links as between resources regardless of representations, using a GET/HEAD to retrieve such relationships is muddled by the existence of a representation context that the UA knows/cares little about. In addition, some UA will impose some representation viewpoint (such as adding an Accept header with some default value) that can skew the value of the returned links without the ability of the application to tell that the links information is different from other representations.

OpenID is one example where today it uses the 'X-XRDS-Location' header to allow using a URI with a valid HTML representation as a user identifier for signing in to sites. So the URI is used for two different things (getting a representation and as a unique identifier used in form entry). The 'X-XRDS-Location' ties the two together by allowing the identity information about the URI to reside elsewhere (in the XRDS document identified by the custom header).

If OpenID is to move to use the more standard Link header the current:

X-XRDS-Location: http://example.com/openid.xrds

Will turn into:

Link: <http://example.com/openid.xrds>; rel="describedby"; type="application/xrds+xml"

But while 'X-XRDS-Location' is a 'resource --> resource' link, the same may or may not be true for Link. What we need is crisp clarity so that applications such as OpenID will know how to address that, by for example, requiring that the Link header above be placed (identically) on all representation of the resource used as an identity identifier.

EHL

Ps. And yes, I am open to discussion about whether the OpenID dual use of a URI (say a blog and an identity identified) is consistent with web architecture. Not promising that such discussion will lead to anything... :-)

---

From: "Williams, Stuart (HP Labs, Bristol)" <[email-masked]>
Date: Thu, 4 Dec 2008 20:13:41 +0000

Hello Eran,

> Sent: 04 December 2008 17:32
> [It takes a while to get used to my style, but while I
> usually talk in absolutes, there are very few things I have
> strong opinions on (this is not one of them). I'm also really
> new to web architecture (I served a 10 year term in
> investment banking before I escaped to a web job).]
>
> The 'canonical' question doesn't apply if you take the view
> that link is between resources and not representations.

So for the sake of this exchange lets just stipulate this to be the case for now (that relations are between resources)...

> But
> it becomes an implementation concern when building an
> application that defines links to be between resources, and
> the Link header is not fully compatible with that.

You'll have to unpack that some more for me to understand unless all your saying is that the Link header draft needs to be updated in line with what we have just stipulated (a few lines above). ie. is there a "But..." if the Link Header draft stated that the header claimed relations are claimed (we'll leave by what or whom asside) to hold between resource pairs?

> Resource
> discovery (XRDS, POWDER, OpenID, etc.) depends on links
> having a resource and not representation context. But again,
> there are easy implementation-based solutions if the spec
> goes the representation way.
>
> I prefer to define links as between resources regardless of
> their representation mostly for the following reasons:
>
> 1. I think links should be symmetric and 'representation -->
> resource' isn't symmetric. 'resource --> resource' is nice and clean.
> 2. If a 'rel' link is defined as 'representation -->
> resource' that forces 'rev' to be 'resource -->
> representation'. It means that 'B --(rev)--> A' has nothing
> to do with 'A --(rel)--> B' because each is between different
> objects (resource / representation).
> 3. The other way to accomplish symmetry is 'representation
> --> representation' which has been rejected here before. That
> would shift the meaning of 'type' from a hint to an actual
> part of the relationship context (needed to define the
> representation of the linked resource in context for the link).

Yes... I think those three points also make the case quite nicely.

> There are clear implications for defining link as
> 'representation --> resource' vs. 'resource --> resource'.
> One of them is the impact of the definition of the 'rel/rev'
> relationship. All I am asking for is clarity.

I'd be interested to know whether we have persuaded Mark (yet)... Mark?

Stuart

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Dec 2008 11:22:42 +1100

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:

> 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.
>
> 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
>
>
>
>>> few
>> semantics
>> those
>>> inter-
>>> does
>> by
>> state -
>> header
>> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
>> Berks
>> RG12 1HN

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Dec 2008 11:57:58 +1100

> I'd be interested to know whether we have persuaded Mark (yet)...  

I think you have.

Looking back at the source text from 2068, it *does* talk about  
resource-to-resource links, and this is supported by the "anchor"  
attribute that Julian reminded us about.

The one quibble I have is with this notion of a "canonical" set of  
links; there can always be more links between resources than are  
serialised into the headers (unless it's specifically required by an  
application; see below). This is important, because it allows (for  
example) an HTML representation to carry HTML-centric links, while  
allowing an XML representation of the same resource to carry XML- 
centric links, if that's what's desirable, without conflicting.

Eran, if you want to say that all responses for a particular resource  
must contain a particular link, go ahead and specify just that; even  
if we clarify Link to say that links *are* resource->resource, there's  
no guarantee or implication that all responses will have a Link  
header...

Cheers,