Re: [apps-discuss] "X-" revisited

Bjoern Hoehrmann <derhoermi@gmx.net> Fri, 08 July 2011 00:12 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5B921F8839 for <apps-discuss@ietfa.amsl.com>; Thu, 7 Jul 2011 17:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.769
X-Spam-Level:
X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnqvDg4HWO8C for <apps-discuss@ietfa.amsl.com>; Thu, 7 Jul 2011 17:12:54 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0F6F121F8837 for <apps-discuss@ietf.org>; Thu, 7 Jul 2011 17:12:53 -0700 (PDT)
Received: (qmail invoked by alias); 08 Jul 2011 00:12:52 -0000
Received: from dslb-094-223-185-199.pools.arcor-ip.net (EHLO HIVE) [94.223.185.199] by mail.gmx.net (mp003) with SMTP; 08 Jul 2011 02:12:52 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+w24dpM3ywGxdQyPYSe4D91NxgFIbh1Y6cK1s+cv Q8+9woWnqZXk+q
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Date: Fri, 08 Jul 2011 02:13:03 +0200
Message-ID: <su8c17pc328e2cpdnn1g1ia8i7n9vnmh2k@hive.bjoern.hoehrmann.de>
References: <4E08CDCB.70902@stpeter.im> <4E13DC15.2080302@stpeter.im>
In-Reply-To: <4E13DC15.2080302@stpeter.im>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] "X-" revisited
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 08 Jul 2011 00:12:56 -0000

* Peter Saint-Andre wrote:
>http://www.ietf.org/id/draft-saintandre-xdash-01.txt

The mechanism here allows to encumber public infrastructure that's been
developed with attention to consensus and decent documentation with uni-
lateral and usually poorly documented extensions. If the mechanism sur-
faces too often, everybody should feel annoyed and desire changes so it
stays in its confined place. You writing this draft tells me that it is
actually working good. Overdoses are supposed to cause problems.

With extension schemes there are things we want to have, things we want
to avoid, there are social and other dynamics, and they vary among pro-
tocols. I would expect an argument against `X-` to establish a context
in this sense, and then show how `X-` is unfit, possibly by showing how
some other mechanism is proved to be better. Your document does not do
that, so I find it rather unconvincing.

I would more generally think extensibility is hard and there is no one
approach suitable for all situations. You recommend for instance that
implementation-specific feature names should include reference to the
implementation. This is done with Cascading Style Sheets, after vendors
have been bitten sufficiently many times that not doing that would have
social repercussions in addition to the technical ones.

That leads to a situation where authors complain they have to specify
`-opera-feature`, `-mozilla-feature`, and so on in order to use certain
features, as the feature in principle is not implementation-specific,
but experimental implementations of it are. That's largely a social de-
fect of course, vendors put more effort into their implementations than
they do with respect to the standardization process; with the argument
above, the complaints are a good thing. But that's rather contentious,
and people regularily ask for a "-wd-" or "-w3c-" or "-x-" prefix. For
them, `-X-` would actually be an improvement (until their stuff breaks).

There is a migration point where implementers move from these prefixes
to the standard name. We largely call that making progress in standar-
dization of the feature, I find it a bit odd that you cite this as the
primary problem with the mechanism here. You actually argue both that
changing the name is a problem, and that the standard name may imply a
different behavior, which is also a problem. I would think the opposite,
standardization allows for corrective actions, so the standardization
is a good thing (you don't say it's bad, but you get close).

With people adding to public infrastructure, I care about avoiding the
issues that very typically arise when documentation is poor or absent
and when those making the additions do not consult with interested but
otherwise independent parties. Whether "X-" is good or bad does not play
a large role in that; I do think a document detailing what we want to
have with extensibility mechanisms, what we want to avoid, what problems
individual approaches have, would be valuable; a document arguing contra
"X-" without the larger discussion, not so much.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/