Re: "why I quit writing internet standards" (Dale R. Worley) Mon, 14 April 2014 21:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 808C31A076A for <>; Mon, 14 Apr 2014 14:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q7jo6mhjFm1p for <>; Mon, 14 Apr 2014 14:44:54 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:64]) by (Postfix) with ESMTP id 807A01A023A for <>; Mon, 14 Apr 2014 14:44:54 -0700 (PDT)
Received: from ([]) by with comcast id pwuR1n0011wpRvQ57xkr1k; Mon, 14 Apr 2014 21:44:51 +0000
Received: from ([]) by with comcast id pxkr1n00J1KKtkw3exkr29; Mon, 14 Apr 2014 21:44:51 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s3ELiplg014506 for <>; Mon, 14 Apr 2014 17:44:51 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id s3ELipR8014504; Mon, 14 Apr 2014 17:44:51 -0400
Date: Mon, 14 Apr 2014 17:44:51 -0400
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
In-reply-to: <>
Subject: Re: "why I quit writing internet standards"
References: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1397511891; bh=sJjPUv7N8mgQ8hSWXicuYZyJpZxzp2LIklqpHSp0HT8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=bChnEZGHL+R4vAChCQ5ldqgDxxIKpTkOf8CcVbiVYGuEzAgPrN8wP9U10f25FeoIy DRbipBM0JoVkh4tu8otwKlE9lXF/u5VhHbIiwISlxXx754QzdFD1Tpq6xYuCyhMUks oLogeQbFd5S7ctR3L2aMUHWLtTUvi+l42sRE+vWSGPaGnbnS7v8f9VPDhBtiumkKDk 2nyDp271X+dPjM4nbYo7SH/2NhzrJ/jx3IsNUe/Mj9Nnzi4JEtaz/VtK3gI+Dp0qmc r5jP5c3a+qq1z3DdTF+CAlIc6ATkTdpvrT3mXVBdapb6nLKkAkrYFZ+ZdibSSBvUiw npaWBGx81hvQA==
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Apr 2014 21:44:59 -0000

> I'm surprised that no one has sent this out yet:
> "Summary: After contributing to standards organizations for more
> than seven years, engineer Vidya Narayanan decided it was time to
> move on. Although she still believes that these organizations make
> the Internet a better place, she wonders about the pace of change
> versus the pace of organizations."

> "while the pace at which standards are written hasn't changed in
> many years, the pace at which the real world adopts software has
> become orders of magnitude faster."

This is key, in a way.  But the pace at which software has been
adopted hasn't changed.  Nor has the pace at which the real world
adopts *interoperable protocols* changed -- and that has always been
much slower.  What has happened is that a lot of the focus (and money
and employment) has moved from adopting new protocols to adopting new
software, software which is under no interoperation constraints.

A simpler comparison is between the compilers for two languages:
Fortran and Perl.  There have been many, many Fortran compilers
written, and at any era, there has been the effort to standardize the
language that the compilers accept, so that a program can be compiled
using more than one compiler.  In reality, to ensure that the
compilers interoperate.

Now look at Perl.  There has only been one compiler in all of history,
so that any Perl program that works on one computer works on every
computer that implements Perl -- because it's always run using the
same compiler.

In this case, it is a side-effect of open source, I think, because
open source eliminates the financial pressure on computer vendors to
write their own compilers for a language.

A similar thing has been happening in other fields.  An internal
feature can be added to Apache and distributed to the world in
months.  But adding a feature to HTTP can take years, because it has
to be designed and implemented to be interoperable -- in this case,
between the HTTP servers and the HTTP clients.

In the current Internet business, a lot of the new business is at the
application layer, and it is composed of "walled garden" web sites,
which don't have to interoperate with anything else.  In the more
elaborate cases, the user's web browser effectively downloads the
client software at the point when the user accesses the server.  There
are no true interoperability constraints.

In situations where you are going to need "two independently-developed
interoperable implementations", a standards process is still needed.
But there are a lot of high-profile situations where that isn't

In regard to speeding up the standards process, it's clear that in
most cases, the process could in principle be carried out much faster.
In all the cases I've observed, the major problem is that the
participants can only spend a small fraction of their working hours on
the standards discussion.  I assume this is because it's rare that
getting the standard completed is gating to shipping their employer's