- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 06 Dec 2008 12:32:34 +0100
- 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 <http://www.w3.org/TR/html4/struct/links.html#h-12.3.1>: "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. > ... Understood. 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