W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

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

From: Phil Archer <phil@philarcher.org>
Date: Wed, 03 Dec 2008 09:53:41 +0000
Message-ID: <49365725.5050806@philarcher.org>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
CC: Eran Hammer-Lahav <eran@hueniverse.com>, Mark Nottingham <mnot@mnot.net>, Drummond Reed <drummond.reed@cordance.net>

I'd just like to jump in on one point:

Eran Hammer-Lahav wrote:
>>>>   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 just wrote out an argument for why I felt it was important to keep 
rev... and realised that my own arguments convinced me that it probably 
isn't needed for HTTP Link after all. The arguments over the relative 
authority and semantics of rel and rev links is pretty compelling.

And yet, and yet... I would still be concerned to see it go because it 
is *really* useful in RDFa. HTML 5 has dropped rev for the link element 
and if the tide is against keeping rev in HTTP Link then the impression 
being given might be that rev is deprecated everywhere. Even though that 
is not what is being said or implied here, it could lead to future 



Phil Archer
w. http://philarcher.org/
Received on Wednesday, 3 December 2008 09:54:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC