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

Randall Gellens <> Mon, 14 November 2011 08:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15BD311E80D3 for <>; Mon, 14 Nov 2011 00:20:33 -0800 (PST)
X-Quarantine-ID: <VjhzHjSEJFep>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -106.273
X-Spam-Status: No, score=-106.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VjhzHjSEJFep for <>; Mon, 14 Nov 2011 00:20:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BF58711E80C6 for <>; Mon, 14 Nov 2011 00:20:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1321258830; x=1352794830; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:content-type:x-random-sig-tag; z=Message-Id:=20<p0624062acae67c872451@[]> |In-Reply-To:=20<> |References:=20<20111024161910.8048.2279.idtracker@ietfa.>=0D=0A=20<p06240623cae622c69b08@[]>=20 <>|X-Mailer:=20Eudora=20for =20Mac=20OS=20X|Date:=20Mon,=2014=20Nov=202011=2000:11:36 =20-0800|To:=20<>|From:=20Randall=20Gell ens=20<>|Subject:=20Re:=20[apps-discu ss]=20I-D=20Action:=20draft-ietf-appsawg-xdash-02.txt|Cc: =20=20Peter=20Saint-Andre=20<>,=20Dave =20Crocker=20<>,=0D=0A=20=20=20=20=20=20 =20=20Mark=20Nottingham=20<>,=20<apps-discus>|Content-Type:=20text/plain=3B=20charset=3D"us -ascii"=20=3B=20format=3D"flowed"|X-Random-Sig-Tag:=201.0 b28; bh=kWg8b4K9TJPbDTHj/FrsaTpwcS9rl/dGLOY/btdMoTo=; b=G5WVJgQ5ZglDTtBJONLtvD0l07urbvoBROA/DS763X7bpzby1XyRn4yH QiAiutRjua0YXnVDFcDTrgIccKaN82cDjR+JyOA/S4kypIdKzIlbHOTnY p/NpDyV/sARorY83TVwY0EkzVpENoqyEbZMJdumT/gRHzDoiPsjznBFwL s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="137362622"
Received: from ([]) by with ESMTP; 14 Nov 2011 00:20:29 -0800
X-IronPort-AV: E=Sophos;i="4.69,504,1315206000"; d="scan'208";a="112898915"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2011 00:20:16 -0800
Received: from [] ( []) by (8.14.2/8.14.2/1.0) with ESMTP id pAE8K8Bb010076; Mon, 14 Nov 2011 00:20:09 -0800
Mime-Version: 1.0
Message-Id: <p0624062acae67c872451@[]>
In-Reply-To: <>
References: <> <p06240623cae622c69b08@[]> <>
X-Mailer: Eudora for Mac OS X
Date: Mon, 14 Nov 2011 00:11:36 -0800
From: Randall Gellens <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
Cc:, Mark Nottingham <>, Dave Crocker <>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.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: Mon, 14 Nov 2011 08:20:33 -0000

At 1:56 PM +0800 11/14/11, Dave CROCKER wrote:

>  On 11/14/2011 10:00 AM, Randall Gellens wrote:
>>  To me, this text points out that sometimes people slap together an 
>> ad-hoc "x-"
>>  parameter, and later go for a standard version, which after wider review is
>>  modified to address security or other issues; the text notes that if this
>  I think the essence of what you've cited is that the later process 
> produces a revised specification.  Hence, what is produced is not 
> the same thing as was getting used.  Unfortunately the implication 
> is a practise of re-using the name without any version indication, 
> which is generally frowned upon, protocol technique-wise...

Right, but the answer, I think, is to use a different name for the 
standardized version, not to do away with wider review.

We saw this in the past few years with IMAP extensions, where a 
proposal used a capability name for the I-D versions, and a new 
capability name for the RFC.

>>  I can't help but think that we'd be better off with a middle 
>> ground, similar to
>>  "vnd." namespace, for ad-hoc parameters that might or might not be 
>> standardized,
>>  but that clearly have not been through IETF consensus.
>  Yuch.

Why?  There are a number of situations where it would be helpful to 
have some namespace distinguisher, including where other SDOs specify 
a set of parameters (as well as case of some implementation wanting 
to use a parameter value for its own purposes).

>   > One advantage is that it
>>  provides some impetus (however slight) to develop a standard version if it's
>>  useful. Another advantage is that it might provide better clues as 
>> to the source
>>  of and change control over the ad-hoc parameter.
>  At base, this would continue the core model that has proved problematic.

But it would improve some of the problems of that model, and avoid 
some of the problems with just abandoning the model entirely.

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never look at the trombones, it only encourages them.
                                   --Richard Strauss