Re: [hybi] deflate-stream and masking

Greg Wilkins <> Thu, 21 July 2011 07:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA07D21F8A97 for <>; Thu, 21 Jul 2011 00:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.823
X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uUXvSHepheiF for <>; Thu, 21 Jul 2011 00:02:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1DA3A21F8877 for <>; Thu, 21 Jul 2011 00:02:56 -0700 (PDT)
Received: by vxi40 with SMTP id 40so854858vxi.31 for <>; Thu, 21 Jul 2011 00:02:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id v2mr163041vdf.375.1311231776449; Thu, 21 Jul 2011 00:02:56 -0700 (PDT)
Received: by with HTTP; Thu, 21 Jul 2011 00:02:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <00b801cc470a$d2d5e520$7881af60$> <> <1311190993.1862.135.camel@ds9> <> <> <>
Date: Thu, 21 Jul 2011 17:02:56 +1000
Message-ID: <>
From: Greg Wilkins <>
To: Hybi <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] deflate-stream and masking
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jul 2011 07:02:57 -0000

On 21 July 2011 12:37, John Tamplin <> wrote:
> At the time, it wasn't divided.  I don't recall any serious objections at
> the time it was proposed and included in the spec, including from you.

I don't recall any discussion at all about the extension.   There was
some talk about the effect of compression, to which there was a
response that spoke against stream compression   The
deflate-stream extension then just appeared in the a draft...  I can't
actually find any thread that proposed it's addition.   I've looked
several times and failed to find any discussion.

Note that I'm not saying that somebody has done some evil deception to
get this into the spec.  Just that when objections have been raised,
then the default position should be that the feature is excluded
unless rough consensus can be achieved.

On 21 July 2011 12:47, David Endicott wrote:
> You sound frustrated, Greg.

Because this is an process anti-pattern that I think is mostly
responsible for much of the difficulties in this WG.   When an idea is
put into the spec, then it has unfair advantage over alternate ideas
and the entire discussion is tainted by the natural tendency to status
quo. Also I just don't understand why when there are many opponents to
this optional feature that we don't just drop it and let the
extensions be proposed in their own drafts and prosper or otherwise on
their own merits - not because they lucked out and became the favoured
son of the core specification.   I'm seen the results of the J2EE
specification process where favoured-son have been picked (Servlets,
no JSPs, no JSFs, no ....) and it is a disaster.