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

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.

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

EHL

Received on Wednesday, 3 December 2008 08:46:14 UTC