Re: Do we now require change control on specifications we use?

Carsten Bormann <> Tue, 04 December 2007 19:04 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Izd3z-0006LJ-Sh; Tue, 04 Dec 2007 14:04:11 -0500
Received: from discuss by with local (Exim 4.43) id 1Izd3y-0006JF-Eu for; Tue, 04 Dec 2007 14:04:10 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Izd3y-0006IT-4n for; Tue, 04 Dec 2007 14:04:10 -0500
Received: from ([2001:638:708:30c9:209:3dff:fe00:7136] by with esmtp (Exim 4.43) id 1Izd3v-0001Pp-PA for; Tue, 04 Dec 2007 14:04:10 -0500
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.0/8.14.0) with ESMTP id lB4J3xhE005762; Tue, 4 Dec 2007 20:03:59 +0100 (CET)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id B0D355D8D; Tue, 4 Dec 2007 20:01:33 +0100 (CET)
Message-Id: <>
From: Carsten Bormann <>
To: Paul Hoffman <>
In-Reply-To: <p06240810c37b49d7ff6c@[]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Do we now require change control on specifications we use?
Date: Tue, 4 Dec 2007 11:00:16 -0800
References: <> <> <p06240810c37b49d7ff6c@[]>
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc:, Carsten Bormann <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Dec 04 2007, at 10:25, Paul Hoffman wrote:

> At 9:29 AM -0800 12/4/07, Carsten Bormann wrote:
>> XML is *not* a moving target.
>> ASN.1 was.  Worse, it was in the control of tool vendors who were  
>> living off changes to the "standard" and increasing complexity in  
>> order to sell upgrades and keep a high barrier to market entry.
> Oh, please. The "added complexity" that was *needed* to be changed  
> in all the PKIX and S/MIME specs to meet the changes over 20 years  
> of ASN.1 changes are minor and cause no bits-on-the-wire changes.

So you were lucky.
(One could also say the writers of those specs had the right "taste"  
in using only features that survived.)

> Blaming this on ASN.1 "tool vendors" is silly. First, there is  
> basically only one significant tool vendor.

See?  The strategy worked for them.
(And yes, "tool vendors" is a simplification -- "that part of the  
ecosystem that benefits from change more than from stability" is a bit  

The end result is that there is a dearth of useful ASN.1 tools.  That  

> More important, however, is that most of the changes have been to  
> add new data formats that the IETF has completely ignored. Those  
> formats (PER, CER, XER, YAER...) were wanted by other SDOs;

There is an interesting push-pull relationship to those desires (as in  
"wanted"), but this is off-topic.

> The changes in ASN.1 have had little or no effect on the IETF.

Because the IETF uncoupled from the "progress" in those cases where it  

> We are considering bringing our specs up to date now, and it is  
> quite easy and completely voluntary.

I was not trying to criticize that.  I still think ASN.1 is a textbook  
example for an external dependency gone wrong, at least for some of  
its customers.  And my point stands that having a dependency on an SDO  
that does not care about you does not help.

Gruesse, Carsten