Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-01.txt

Peter Saint-Andre <> Fri, 21 October 2011 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59A8E11E8080 for <>; Fri, 21 Oct 2011 15:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5702ky8VCI8C for <>; Fri, 21 Oct 2011 15:47:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 546C311E8073 for <>; Fri, 21 Oct 2011 15:47:00 -0700 (PDT)
Received: from squire.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 6085541E49; Fri, 21 Oct 2011 16:52:02 -0600 (MDT)
Message-ID: <>
Date: Fri, 21 Oct 2011 16:46:49 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Murray S. Kucherawy" <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.2
OpenPGP: url=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Oct 2011 22:47:01 -0000

On 10/21/11 1:51 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From:
>> [] On Behalf Of Peter
>> Saint-Andre Sent: Tuesday, October 18, 2011 1:42 PM To:
>> Subject: Re: [apps-discuss] I-D Action:
>> draft-ietf-appsawg-xdash-01.txt
>> On 10/18/11 2:33 PM, wrote:
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories. This draft is a work item of the
>>> Applications Area Working Group Working Group of the IETF.
>>> Title           : Deprecating Use of the &quot;X-&quot; Prefix
>>> in Application Protocols Author(s)       : Peter Saint-Andre D.
>>> Crocker Mark Nottingham Filename        :
>>> draft-ietf-appsawg-xdash-01.txt Pages           : 12 Date
>>> : 2011-10-18
>> The diff is here:
>> Thanks to Alexey Melnikov for the review that prompted this
>> revision.
> Hi Peter,
> I like this a lot. Simple, to the point, excellent delivery of the
> history.

On behalf of my co-authors, I say thanks!

> After re-reading it from top-to-bottom, the only gripe I have is
> that, in the second paragraph of Section 1, the use of "advancement"
> feels ambiguous.  Was said "advancement" because the experimental
> namespace leaked into the standard namespace, or because what we
> might expect as "advancement" (i.e., registration) has been more
> expensive than it's worth?

I see two kinds of cost here:

1. Experimental parameters become de facto standards, which confuses
people because they tend to think that "it starts with 'x-' so it must
not be a standardized parameter" (etc.). Such confusion wastes valuable
mental energy.

2. Some people want de facto standards to become de jure standards,
which means they have to jump through hoops, perhaps change the
parameter name, encourage developers to implement code for the new name
in addition to the old name, etc.

In general, I prefer "leakage" to "advancement" because it has less
tincture of movement up a standards track as in RFC 2026.

> The idea of advancement from non-standard space to standard space to
> me suggests the dropping of "X-", but that's exactly what you're
> saying isn't happening when it should.
> The question is really answered in the appendices quite clearly, but
> it seems having to go there to figure out what this paragraph means
> suggests a bit more detail here is needed.
> I suggest:
> Although in theory the "X-" convention was a good way to avoid 
> collisions (and attendant interoperability problems) between
> standard parameters and non-standard parameters, in practice the
> costs associated with the advancement of non-standard parameters into
> the standards space, without proper conversion and registration, have
> outweighed the benefits. Therefore this document deprecates the "X-"
> convention for most application protocols and makes specific
> recommendations about how to proceed in a world without the
> distinction between standard and non-standard parameters.
> ...or something like that.

Or just change "advancement" to "leakage", perhaps?

> Otherwise, nice work!



Peter Saint-Andre