- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 06 Dec 2008 12:01:06 +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: > ... > If we disallow inbound links (i.e., take them out of the prose, but as > Roy says, still allow them in the syntax, for compatibility), we'll > avoid this confusion and also gain some consistency between the > serialisations. The only apparent loss is that of inbound links, and if > I had to characterise the discussion I've seen so far, it's that their > proponents think that they'd be *nice* to have, but I don't see anybody > lying down in the road to save inbound links; indeed, when we re-added > them, it was based on one or two people saying as much, IIRC. > > Have I missed something? Otherwise it looks like we're moving towards > taking 'rev' out (but still allowing it as a link-extension > syntactically). Note that we're still going to update to say that rel > links are resource->resource. > ... 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. 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. 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. BR, Julian
Received on Saturday, 6 December 2008 11:01:52 UTC