- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Dec 2008 21:42:40 +1100
- To: Eran Hammer-Lahav <eran@hueniverse.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 3 December 2008 10:43:25 UTC