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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BEEC1F0C49; Sun, 13 Nov 2011 18:20:30 -0800 (PST)
X-Quarantine-ID: <SfPTPCB93Rnd>
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.276
X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SfPTPCB93Rnd; Sun, 13 Nov 2011 18:20:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 850B71F0C46; Sun, 13 Nov 2011 18:20:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1321237229; x=1352773229; h=message-id:x-mailer:date:to:from:subject:cc:content-type: x-random-sig-tag; z=Message-Id:=20<p06240625cae62b4d9a81@[]> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sun,=201 3=20Nov=202011=2018:20:17=20-0800|To:=20<internet-drafts@>,=20Peter=20Saint-Andre=20<>, =0D=0A=20=20=20=20=20=20=20=20Dave=20Crocker=20<dcrocker@>,=20Mark=20Nottingham=20=20=20<> |From:=20Randall=20Gellens=20<> |Subject:=20Re:=20[apps-discuss]=20I-D=20Action:=20draft- ietf-appsawg-xdash-02.txt|Cc:=20<> |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=20 =3B=20format=3D"flowed"|X-Random-Sig-Tag:=201.0b28; bh=+61EcHAU5XTtCnH4GxVcJjWLBMkzsMMNy/nAG6fx39g=; b=edmy93bzrTgqNR3vy7LEcdJTrAG5vEK9YMrrnGZQ8kiWtw+eMKMt6oFb Jji1bdScEaUcahr+p5qZy4O5BEeq55wE/27yhDU6pLXGBw5uRmz2Lp1nF fQ2yspkoXp2/VULqJQV5irf6ekgz9S3KQhxNBSWPV42CsZ7z9OeFP5rrX s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6529"; a="134957402"
Received: from ([]) by with ESMTP; 13 Nov 2011 18:20:29 -0800
X-IronPort-AV: E=Sophos;i="4.69,502,1315206000"; d="scan'208";a="112678273"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2011 18:20:22 -0800
Received: from [] ( []) by (8.14.2/8.14.2/1.0) with ESMTP id pAE2KIP3017198; Sun, 13 Nov 2011 18:20:19 -0800
Mime-Version: 1.0
Message-Id: <p06240625cae62b4d9a81@[]>
X-Mailer: Eudora for Mac OS X
Date: Sun, 13 Nov 2011 18:20:17 -0800
To:, Peter Saint-Andre <>, Dave Crocker <>, Mark Nottingham <>
From: Randall Gellens <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
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 02:20:30 -0000

One thing I noticed is that the text in Appendix B, to me, makes an 
argument for preserving some mechanism to distinguish between 
standard and ad-hoc:

    Furthermore, often standardization of a non-standard parameter or
    protocol element leads to subtly different behavior (e.g., the
    standard version might have different security properties as a result
    of security review provided during the standardization process).  If
    implementers treat the old, non-standard parameter and the new,
    standard parameter as equivalent, interoperability and security
    problems can ensue.

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 happens, and if implementations treat the 
old and new versions as identical, then they are being exposed to the 
vulnerabilities.  However, the solution proposed here means that, 
once an ad-hoc version is deployed, there won't be a standard 
version, and hence no wider review, no revised version with a non-x 
name, and no chance for implementations to avoid the problems.  It 
seems to me that it would be better for the standard version to 
deprecate the non-standard in these cases, or at least describe how 
to avoid its problems.

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.  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.

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.               --Robert Benchley
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It has always seemed to me that the most difficult part of building
a bridge would be the start.                      --Robert Benchley