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


Hi Eran,

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

When type is missing, the server is not providing any hint, and the  
client can resort to conneg.
> Content-type: text/html
> Link: <>; 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

It is just (1) with the type being a hint to the media type of that  

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

I don't think the type provides such a guarantee.
>> 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.

HTML/Atom link elements offer the same kind of flexibility. The source  
is a representation, and the target could be one of the following:

a. A different representation of the same resource
b. Another resource
c. A specific representation of another resource.


Received on Wednesday, 3 December 2008 19:27:01 UTC