- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 21 Aug 2009 17:48:12 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Anne van Kesteren <annevk@opera.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 UTC