Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt
Mark Nottingham <mnot@mnot.net> Fri, 22 January 2010 01:02 UTC
Return-Path: <mnot@mnot.net>
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 E800228C116 for <apps-discuss@core3.amsl.com>; Thu, 21 Jan 2010 17:02:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.445
X-Spam-Level:
X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=-1.846, 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 m5nX93VhezZ8 for <apps-discuss@core3.amsl.com>; Thu, 21 Jan 2010 17:02:51 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 91E2128C10F for <discuss@apps.ietf.org>; Thu, 21 Jan 2010 17:02:51 -0800 (PST)
Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 60B3322E247; Thu, 21 Jan 2010 20:02:45 -0500 (EST)
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: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <4B58574B.4050204@gmx.de>
Date: Fri, 22 Jan 2010 12:02:42 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE77FC83-4137-421B-9511-02B13642AE1A@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
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: Fri, 22 Jan 2010 01:02:53 -0000
On 22/01/2010, at 12:31 AM, Julian Reschke wrote: > > So the grammar in <http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5> lists it as regular link parameter: > > link-param = ( ( "rel" "=" relation-types ) > | ( "anchor" "=" <"> URI-Reference <"> ) > | ( "rev" "=" relation-types ) > | ( "hreflang" "=" Language-Tag ) > | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) > | ( "title" "=" quoted-string ) > | ( "title*" "=" enc2231-string ) > | ( "type" "=" type-name "/" subtype-name ) > | ( link-extension ) ) > > On the other hand, <http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.3> states: > > The relation type of a link is conveyed in the "rel" parameter's > value. Note that the "rev" parameter has also been used by some > formats, and MAY be accommodated as a link-extension, but its use is > neither encouraged nor defined by this specification. > > So the ABNF defines it as parameter, but the prose claims it's not specified, and could be specified later on as extension. I'm happy to remove it from the BNF if that doesn't disturb the very delicate consensus we have on this topic. Comments from others? > Speaking of which, how do I define an extension? Standards Track RFC updating this one, as there is no registry? If you like. Practically speaking, I think many extensions will be used without such registration, as they'll be specific to the format and/or application in use -- which I think is just fine. > Later on, in the section about HTML4 we find (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>): > > HTML4 also has a "rev" parameter for links that allows a link's > relation to be reversed. The Link header does not define a > corresponding "rev" parameter to allow the expression of these links > in HTTP headers, due to the confusion this mechanism causes as well > as conflicting interpretations (briefly, some hold that rev reverses > the direction of the link, while others that it reverses the > semantics of the relation itself). > > I have to admit that I'm still not sure what *in practice* the difference between reversing the link direction and reversing the link semantics actually is. (Example?) I can add a brief example for the latter. > So my preference would be to actually define the rev parameter consistently with this, and then to discourage it's use due to the other good reasons we heard about that (such as HTML authors typing "rev" instead of "rel"). 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). Cheers, -- Mark Nottingham http://www.mnot.net/
- Fwd: New Version Notification - draft-nottingham-… Mark Nottingham
- Re: Fwd: New Version Notification - draft-notting… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Jan Algermissen
- anchor parameter - LC comment on draft-nottingham… Julian Reschke
- rev parameter - LC comment on draft-nottingham-ht… Julian Reschke
- parameter quoting - LC comment on draft-nottingha… Julian Reschke
- editorial LC comments on draft-nottingham-http-li… Julian Reschke
- exposing sensitive information in URIs - LC comme… Julian Reschke
- Re: parameter quoting - LC comment on draft-notti… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Mike Burrows
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- Re: parameter quoting - LC comment on draft-notti… Mike Burrows
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: parameter quoting - LC comment on draft-notti… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: editorial LC comments on draft-nottingham-htt… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: parameter quoting - LC comment on draft-notti… Julian Reschke
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- Re: New Version Notification - draft-nottingham-h… Jan Algermissen
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Mark Nottingham
- Re: exposing sensitive information in URIs - LC c… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: editorial LC comments on draft-nottingham-htt… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Anne van Kesteren
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: rev parameter - LC comment on draft-nottingha… Roy T. Fielding
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke