Re: [hybi] deflate-stream and masking

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D26C21F86DC for <>; Wed, 20 Jul 2011 19:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, 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 UklWSVUhUyN9 for <>; Wed, 20 Jul 2011 19:29:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9815A21F86D6 for <>; Wed, 20 Jul 2011 19:29:16 -0700 (PDT)
Received: by vxi40 with SMTP id 40so735361vxi.31 for <>; Wed, 20 Jul 2011 19:29:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id br17mr5388234vdc.107.1311215355480; Wed, 20 Jul 2011 19:29:15 -0700 (PDT)
Received: by with HTTP; Wed, 20 Jul 2011 19:29:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <00b801cc470a$d2d5e520$7881af60$> <> <1311190993.1862.135.camel@ds9> <>
Date: Thu, 21 Jul 2011 12:29:15 +1000
Message-ID: <>
From: Greg Wilkins <>
To: Peter Saint-Andre <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Hybi <>, Patrick McManus <>
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 02:29:17 -0000

On 21 July 2011 05:48, Peter Saint-Andre <> wrote:
> My reading of the discussion is that people don't necessarily want to throw
> out deflate-stream, but they don't think it belongs in the base spec and
> they would prefer to see it defined in a separate draft, just as you propose
> for deflate-frame.

My reading is that there is a mix of opinions.  Some want it thrown
out, others want to keep it.

What I want to know is how (yet again) has a feature with such divided
support made it into the spec.  Why does this WG insist on putting non
consensus features into the spec and then having the argument to
remove them or not.   The status quo should not be to have a
non-consensus feature included.    It should be for the proponents of
a feature to make their case for inclusion and not for the opponents
to make the case for exclusion.

While it would be good for the base spec to have both compression and
an exemplar extension - that is no reason to just accept any old
extension that is neither good compression nor a good exemplar.

I also understand the argument that deflate-frame should just be
written up in another draft - by why does that not also apply to

If we are going to have a favoured son, can't we pick the healthy one
with some good prospects rather than the black sheep that is going to
end up dead or in jail?