Re: [hybi] deflate-stream and masking

David Endicott <> Thu, 21 July 2011 02:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5368021F85B1 for <>; Wed, 20 Jul 2011 19:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tWRrMdPEb-X6 for <>; Wed, 20 Jul 2011 19:47:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 339D421F854E for <>; Wed, 20 Jul 2011 19:47:41 -0700 (PDT)
Received: by wyj26 with SMTP id 26so637656wyj.31 for <>; Wed, 20 Jul 2011 19:47:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kaz0ckSl/WnTp37zmydzh3HxIBSDbKCfsV8BI/zVEnk=; b=DAAHRB+Yv+twk5wJih/+v1PhLK5KWAyXaJ2mXimapehwd1ksP8yy9rVhsCGhbD8xYS 23f7CYSHYzByXpUWJiSdyg2CuiMxLI3T/x9j8MyEuam1khc/qXo5w16t2ikCADNc6U3p pAnY2ef1V51n0Y1jILi69yxX013qEDXho2qVg=
MIME-Version: 1.0
Received: by with SMTP id h52mr7929245wee.33.1311216459940; Wed, 20 Jul 2011 19:47:39 -0700 (PDT)
Received: by with HTTP; Wed, 20 Jul 2011 19:47:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <00b801cc470a$d2d5e520$7881af60$> <> <1311190993.1862.135.camel@ds9> <> <>
Date: Wed, 20 Jul 2011 22:47:39 -0400
Message-ID: <>
From: David Endicott <>
To: Greg Wilkins <>
Content-Type: multipart/alternative; boundary=000e0cd342b651830804a88b5f06
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:47:42 -0000

You sound frustrated, Greg.    I understand that.

On the one hand, we could throw our hands up in frustration and either start
over, or fork the existing work.   Either way, the browser vendors would
need to ratify (by implementing) the protocol.

On the other hand, we could push the current design to standardization, so
that the browser vendors can do final implementation and we all can start
using the 20% of it that isn't borked.  Of course, if we remove a feature or
three beforehand, then the browser folks have to do less and can ship

Please try to forgive the dreamers who have gilded our kitchen sink.   It is
a thrilling and intoxicating thing to do protocol design - it leads one to
do stuff because you can imagine it, not because it's actually needed.

I'd be happy to help with whichever of the above courses of action that
 gives me a lightweight asynchronous persistant connection between scripts
running in an easily available, off the shelf, bog standard browser client
and whatever server abomination I come up with, as soon as possible.

On Wed, Jul 20, 2011 at 10:29 PM, Greg Wilkins <> wrote:

> 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
> deflate-stream?
> 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?
> regards
> _______________________________________________
> hybi mailing list