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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 06 Dec 2008 12:32:34 +0100
Message-ID: <493A62D2.5040000@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>, Ian Hickson <ian@hixie.ch>, Drummond Reed <drummond.reed@cordance.net>, Phil Archer <phil@philarcher.org>

Mark Nottingham wrote:
> ...
>> So how would that work precisely?
>> If "rev" is taken out, the presence of a "rel" parameter becomes 
>> mandatory, right?
>> In that case, "rev" can not be introduced as an extension anymore -- 
>> either headers using "rev" would need to *also* contain a "rel" value 
>> to stay valid (breaking the intended semantics), or would need to be 
>> invalid in that they do not contain the "rel" parameter.
> ... or rel would need to no longer be required. In 2068, neither rel nor 
> rev was required...

Indeed, nor in HTML4.

Interesting enough, HTML4 even says in 

"12.3.1 Forward and reverse links

The rel and rev attributes play complementary roles -- the rel attribute 
specifies a forward link and the rev attribute specifies a reverse link.

Consider two documents A and B.

Document A:       <LINK href="docB" rel="foo">

Has exactly the same meaning as:

Document B:       <LINK href="docA" rev="foo">

Both attributes may be specified simultaneously."

(Note the last sentence)

>> So it seems that "rev" can not be introduced as an *extension* at a 
>> later point, it would be a major change of the specification.
>> If "rev" is to be taken out, the spec should state that the semantics 
>> of links without "rel" is undefined, and that future specifications 
>> can change that.
> Yes, I think that's roughly where we're at.
>> That being said, I think the semantics of "rev" are clear enough; so I 
>> would recommend keeping it but maybe to add language discouraging its 
>> use for now.
> Hmm. Defining it but discouraging its use?
> To be clear -- I don't have strong feelings one way or another. However, 
> I do think that rev is one of the more tentative parts of the spec as it 
> sits.
> ...


We should consider the cost of both proposals. The point I'm trying to 
make is that re-adding "rev" at a later point of time is more complex 
than simply adding an extension. So my personal preference (not based on 
any real world use cases, I admit) is to keep it, but to explain the 
potential issues.

BR, Julian
Received on Saturday, 6 December 2008 11:33:19 UTC

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