Re: [hybi] deflate-stream and masking

[John Tamplin <[e-mail]>]

On Thu, Jul 21, 2011 at 3:02 AM, Greg Wilkins <[e-mail]> 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
> http://www.ietf.org/mail-archive/web/hybi/current/msg01811.html   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
http://www.ietf.org/mail-archive/web/hybi/current/msg04071.html, where
you commented only about allocating bits in a fixed manner and how
extensions were named, nothing about the basic operation of the
extension.

Patrick then made an official proposal in the thread starting at
http://www.ietf.org/mail-archive/web/hybi/current/msg04117.html.

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