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

Mark Nottingham wrote:
> 
> 
> On 03/12/2008, at 7:45 PM, Eran Hammer-Lahav wrote:
> 
>> On 02/12/2008, at 5:38 PM, Mark Nottingham wrote:
>>>
>>> On 02/12/2008, at 6:33 PM, Eran Hammer-Lahav wrote:
>>>>>
>>>>> 1.  Introduction
>>>>>
>>>>>  This document defines typed link relations, independent of the
>>>>>  context they occur in.  It does so by clarifying the status of the
>>>>
>>>> I think 'context' needs to be clarified to mean 'content type' or
>>>> 'transport'. Without the next sentence, this seems to imply that
>>>> instances of the Link header are not context-sensitive, which they
>>>> are (resource, representation, etc.).
>>>
>>> I'm not sure what you're getting at here; this sentence isn't talking
>>> about the Link header at all...
>>
>> Link header is just one instance of 'typed link relations'. The first 
>> time read this, before reading the next sentence, I was a bit confused 
>> as to what you meant by 'context'. It might just be my expectations 
>> from reading the previous draft which was about Link headers.
> 
> OK, I'll try to re-read with a fresh eye and see if I can clarify.
> 
> 
>>
>>
>>>>>  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.
>>
>> For my use cases, I can live with the application specifying how this 
>> should be handled.
>>
>>>>>  Each link-value MUST have at least one "rel" or "rev" parameter
>>>>> whose
>>>>>  value indicates the relation type.  If the "rel" parameter is
>>> used,
>>>>>  it indicates that the link's direction for that relation type is
>>>>>  outbound; if the "rev" parameter is used, the given relation
>>> type's
>>>>>  direction is inbound.
>>>>
>>>> Is 'rev' considered as authoritative as 'rel' (as in, 'type' is non-
>>>> authoritative, just a hint)? Forward looking links using 'rel' are
>>>> clearly authoritative as they indicate the view-point of the
>>>> resource, which has the authority to declare its own perceive links
>>>> to other resources. However, 'rev' can go both ways. It seems to be
>>>> semantically equivalent to an identical 'rel' coming from the linked
>>>> resource. For example:
>>>>
>>>> Resource A: Link: <http://example.com/b>; rel="friend"
>>>> Resource B: Link: <http://example.com/a>; rev="friend"
>>>>
>>>> If the two are semantically identical, 'rev' must be non-
>>>> authoritative as it serves as a hint as to what another resource
>>>> view the relationship as: "A declares B to be <<its friend>>, B
>>>> hints that A <<declares B its friend>>". However, if 'rev' is meant
>>>> to be authoritative, the two links above cannot be semantically the
>>>> same, as they read: "A declares B to be <<its friend>>, B declares
>>>> that A <<consider it a friend>>". The question is, is 'rev' simply
>>>> an implied 'rel' from the other direction (and so, non-
>>>> authoritative), or 'rev' is a reverse "opinion" of 'rel' which is
>>>> completely relative to the resource regardless of any actual 'rel'
>>>> from the other direction (and so, authoritative).
>>>
>>> This draft isn't attempting to establish a framework for semantics or
>>> trust, and I'm tempted to take out anything that might imply this...
>>
>> I think at a minimum it needs to clearly define the relationship 
>> between 'rel' and 'rev'. This is why I liked it better when 'rev' was 
>> dropped. If you only have 'rel', you can express 'rev' with another 
>> 'rel' value, and that will solve my issue. If you keep both, I can't 
>> see how you can avoid explaining their relationship to one another as 
>> listed in the example above.
> 
> 
> I think the issue here is more around trust than just semantics; i.e., 
> you need to know the source of the statement to evaulate it. The thing 
> is, that's really defined by the context of use; i.e., if you're working 
> from within some wonderful semantic framework, you might be able to 
> trust inbound links.
> 
> So, if this were defined by the application, would you be more happy? 
> The effect on *this* spec, I think, would be that the link *header* 
> section would say that rev links aren't necessarily authoritative.
> 
> Make sense?s

Makes sense to me, yes. The problem is that HTTP is generally seen as 
authoritative (the thrust of 
http://www.w3.org/2001/tag/doc/mime-respect) so this spec will need to 
be clear that applications should treat an inbound (rev) link is an 
exception to this. That might be too close to going against a TAG 
finding for some??

-- 

Phil Archer
w. http://philarcher.org/

Received on Wednesday, 3 December 2008 10:58:03 UTC