Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01

Peter Saint-Andre <stpeter@stpeter.im> Mon, 25 October 2010 22:44 UTC

Return-Path: <stpeter@stpeter.im>
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 C04873A6AEC for <apps-discuss@core3.amsl.com>; Mon, 25 Oct 2010 15:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Level:
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 9CENtyEZ6kB4 for <apps-discuss@core3.amsl.com>; Mon, 25 Oct 2010 15:44:45 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E38D03A6A63 for <apps-discuss@ietf.org>; Mon, 25 Oct 2010 15:44:44 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7D33F40D1E; Mon, 25 Oct 2010 16:54:24 -0600 (MDT)
Message-ID: <4CC608C4.8040209@stpeter.im>
Date: Mon, 25 Oct 2010 16:46:28 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
References: <201010212030.WAA26704@TR-Sys.de> <DFFD2700-C4DF-4256-BA20-03C45F5BAB54@standardstrack.com> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms090102000307050204030302"
Cc: Discuss Apps IETF <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01
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: Mon, 25 Oct 2010 22:44:51 -0000

On 10/25/10 4:42 PM, Thomson, Martin wrote:
> On 2010-10-26 at 02:50:31, Eric Burger wrote:
>> What is the difference between X-mumble and Eric-mumble?  Does
>> private namespaces really help the fundamental problem?
> 
> Namespaces are the root of the problem, aren't they?
> 
> X- is just a (slum) namespace.  Nothing works here.
> 
> Eric-mumble is worse because Albert doesn't like Eric and so he
> duplicates the functions in his own namespace rather than cede
> control to Eric.  (BTW, that's an argument I don't see in the
> draft.)

Many arguments are not yet in the draft, and I shan't have time to
update it before the cutoff. But perhaps a discussion at the appsarea
meeting in Beijing would be productive.

> Better to make your extensibility simple.  How about having three
> tiers of "interoperability protection":
> 
> IP-C: Anyone can use a header with any name they choose.
> 
> Use at own risk.
> 
> IP-R: Anyone can register a header with any name.
> 
> Collisions are less likely, not impossible.
> 
> IP-S: RFCs* register headers with absolute exclusivity.
> 
> Safe to use.

Could you compare / contrast to provisional vs. permanent registrations?
The latter distinction might give us most or all of what we need
(depending on which problem we're trying to solve).

> Because the name isn't scope or qualified, headers can increase their
> interoperability protection status without breaking implementations
> that already use it.  This encourages the registration of headers
> with appropriate names.
> 
> The registry provides a limited guarantee of uniqueness.
> 
> * An standards track registration - or something similarly strong -
> causes existing registrations for the same name get swept away.  The
> review process can determine if this is appropriate.

Fun. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/