W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: [draft-nottingham-http-link-header-06] rev

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 21 Aug 2009 17:48:12 +1000
Cc: Anne van Kesteren <annevk@opera.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D155AF80-DCB1-4A8C-B2C9-D20037FEA234@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
I know where you're coming from.

However, rev's semantics are *extremely* muddy and effectively format- 
specific; I think we're already at the point where it is re-defined  
every time it's used. And, defining it syntactically in Link without  
defining its semantics doesn't seem like the right thing to do.

Thus, it seems to me that the options are to either take it out of the  
syntax completely, or leave it in the syntax for the sole purpose of  
deprecating it (since we can't really define crisp semantics for it).


On 21/08/2009, at 5:21 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> On 25/07/2009, at 12:01 AM, Anne van Kesteren wrote:
>>> If we can consider the media attribute to be an link-extension,  
>>> why can we not do the same for rev?
>> As per recent discussion, done; see
>>  http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html 
>>  ...
>
> I still think this is the wrong approach.
>
> "rev" has been defined in RFC2068. We can explain why relying on it  
> is a bad idea, and suggest alternatives.
>
> But excluding it from the base definition essentially allows re- 
> defining it as extension meaning something else, and that would be  
> bad if a recipient implements RFC2068.
>
> BR, Julian


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 21 August 2009 07:48:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT