Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt

"Roy T. Fielding" <fielding@gbiv.com> Thu, 04 February 2010 22:06 UTC

Return-Path: <fielding@gbiv.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F421728C0CE for <apps-discuss@core3.amsl.com>; Thu, 4 Feb 2010 14:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOY2O1RsmSAA for <apps-discuss@core3.amsl.com>; Thu, 4 Feb 2010 14:06:45 -0800 (PST)
Received: from spaceymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 1DFE23A6E61 for <discuss@apps.ietf.org>; Thu, 4 Feb 2010 14:06:45 -0800 (PST)
Received: from [192.168.1.66] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) by spaceymail-a4.g.dreamhost.com (Postfix) with ESMTP id AA0D1161472; Thu, 4 Feb 2010 14:07:32 -0800 (PST)
Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net>
Date: Thu, 04 Feb 2010 14:07:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <FE77FC83-4137-421B-9511-02B13642AE1A@mnot.net> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1077)
X-Mailman-Approved-At: Fri, 05 Feb 2010 09:27:02 -0800
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2010 22:06:46 -0000

On Feb 3, 2010, at 10:17 PM, Mark Nottingham wrote:

> At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by updating the document, for parameters common to many relation types, or on a per-type / per-application basis). 

I think we are going around in circles.  The normal way to document a
deprecated protocol feature is to include it in the ABNF and state
that it is deprecated in the prose.  Just like obs-text in HTTP.
Otherwise, we'll just keep getting asked "what happened to rev?"  

> On 22/01/2010, at 8:09 PM, Julian Reschke wrote:
>>> As previous discussed (quite a bit), HTML2 defines REV as having reversed *semantics*, while HTML4 talks about it creating a "reverse link" -- which are very different things. This feels like a rat hole to me (thus my attempts to navigate around it).
>> 
>> Again, HTML 2 defines it as:
>> 
>>   REV
>>           same as the REL attribute, but the semantics of the
>>           relationship are in the reverse direction. A link from A
>>           to B with REL="X" expresses the same relationship as a
>>           link from B to A with REV="X". An anchor may have both
>>           REL and REV attributes.
>> 
>> (<http://tools.ietf.org/html/rfc1866#section-5.7.3>)
>> 
>> That totally sounds like "reverse link" to me. So, I really really think there's less confusion than some people claim.

A reverse link would show up as a potential transition from B if
you are currently at B.  That terminology is from hypertext research
where link servers would maintain a database of all links.  That is
why the HTML4 definition is confusing to folks who have worked with
traditional hypertext systems, since the Web does not maintain reverse
links (other than via external services like a CMS or Google).

Anyways, it doesn't matter whether people are confused or not.
What matters is that the HTML2 definition of rev defines how the
technology actually works, whereas the HTML4 definition adds a
bunch of hand-waving and then misuses hypertext terminology in
order to explain what it "means" -- the result is neither technically
correct nor consistent with other hypertext systems, even if it
can be read the same way if we twist our heads a certain direction,
close one eye, and pretend we are in Kansas.

....Roy