Re: [hybi] deflate-stream and masking

John Tamplin <> Thu, 21 July 2011 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AE8A21F8B83 for <>; Thu, 21 Jul 2011 01:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.902
X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KHlTXVXCeEq0 for <>; Thu, 21 Jul 2011 01:48:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 73C3521F8B81 for <>; Thu, 21 Jul 2011 01:48:44 -0700 (PDT)
Received: from ( []) by with ESMTP id p6L8mg92014528 for <>; Thu, 21 Jul 2011 01:48:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=beta; t=1311238123; bh=6SB+FfIBKjegaG7R3FbSk1n8h3U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=izBEyJ8ARbIllfHDCnyzir3cGEVs8UHvjwXWPUnii9Vq0Cqg7OC3Kf/ii0g1+Qi08 Xx4yA04erHzm2FdH0ha3w==
DomainKey-Signature: a=rsa-sha1; s=beta;; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=XxSdEtytyanNT27Dxoe80bzpY56Mip4aVhCN5WT/wdPKy8CTi02R+ZRgBSqXIpsEu ej1LaJdRi1RRd68/JsT2Q==
Received: from yib12 ( []) by with ESMTP id p6L8mOQN012945 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <>; Thu, 21 Jul 2011 01:48:41 -0700
Received: by yib12 with SMTP id 12so633096yib.2 for <>; Thu, 21 Jul 2011 01:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ZQ6duq5Nrhc4Ggb0kPJs8mqMx4NMysmA+M/aJn3t/7w=; b=c1l7hGwuY1jq9fWBsRul7moOuxkRs0mTJfF7Ci9sedSDZDP5VNtLQxiiyWfeKeT2o6 L+0EaNQPregrzR14kBDg==
Received: by with SMTP id w7mr351723yba.116.1311238121186; Thu, 21 Jul 2011 01:48:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 21 Jul 2011 01:48:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <00b801cc470a$d2d5e520$7881af60$> <> <1311190993.1862.135.camel@ds9> <> <> <> <>
From: John Tamplin <>
Date: Thu, 21 Jul 2011 04:48:21 -0400
Message-ID: <>
To: Greg Wilkins <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Hybi <>
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 08:48:45 -0000

On Thu, Jul 21, 2011 at 3:02 AM, Greg Wilkins <> wrote:
> 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.

"hybi deflate-stream" found it immediately for me in my mailbox, and
then it was easy to find the other threads from there.

Patrick first discussed it in a thread starting at, where
you commented only about allocating bits in a fixed manner and how
extensions were named, nothing about the basic operation of the

Patrick then made an official proposal in the thread starting at

The only dissent was me suggesting changing the name from deflate to
deflate-stream, so it went into the next revision of the spec.

> 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.

I believe the first objections to it were raised months after it was
added to the spec, only after we had argued through masking.  So, I
think it is not correct to say that this was added to the spec over
objections and then it is unfairly harder to remove later.  There were
cases earlier where the previous editor did take unilateral action to
put new things into the spec, but that has not been the case here.

Once we do agree on something, I think it is entirely correct that
there is a higher bar necessary to remove it or else we will never
make progress.  Having new information to bring to the discussion,
such as after we added masking, is an adequate reason to reopen the
discussion, which is what we have been doing.

Personally, I think having a weak compression extension in the base
spec is better than no compression at all, so I would object to
removing it but would not object to replacing it with deflate-frame,
if doing so does not delay finalizing the spec.

John A. Tamplin
Software Engineer (GWT), Google