Re: [hybi] deflate-stream and masking

Patrick McManus <pmcmanus@mozilla.com> Wed, 20 July 2011 19:43 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19121F8A62 for <hybi@ietfa.amsl.com>; Wed, 20 Jul 2011 12:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf8Qxj3pt-0q for <hybi@ietfa.amsl.com>; Wed, 20 Jul 2011 12:43:21 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6683A21F8922 for <hybi@ietf.org>; Wed, 20 Jul 2011 12:43:21 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 8095510190; Wed, 20 Jul 2011 15:43:20 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 2E2B310154; Wed, 20 Jul 2011 15:43:16 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: David Endicott <dendicott@gmail.com>
In-Reply-To: <CAP992=Gvz7CT=fZSX=t_7J3YAGF7kKsA9a6M0UQJP3HXxMBANQ@mail.gmail.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com> <CAH_y2NFMdr1ZU2dfy9mCRepZc2R_hnzg0oa3kYPKhWY-FX_8Og@mail.gmail.com> <CAE8AN_V-P2L0mVwjPQYxAypJ67=QWKAhWnDqrM_XmDQXjJbEHA@mail.gmail.com> <CAP992=HmZM9H2i+rFLVNrJVzfQT2qSPzWRm4gQXc2wTQ8fdBTA@mail.gmail.com> <00b801cc470a$d2d5e520$7881af60$@noemax.com> <CAP992=Gvz7CT=fZSX=t_7J3YAGF7kKsA9a6M0UQJP3HXxMBANQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 20 Jul 2011 15:43:13 -0400
Message-ID: <1311190993.1862.135.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2011 19:43:22 -0000

On Wed, 2011-07-20 at 14:55 -0400, David Endicott wrote:
> I'm basing my position on Greg's comment above that:
> 
> 
> > I've just noticed that the w3c is currently intending to make
> support
> > for deflate-stream mandatory!
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
> 

The bug references the editor's draft (i.e. a work in progress) of the
API, which I would hope could still be changed.

Specifically what it does is, as I read it, is mandate that clients
implementing the JS API (i.e. browsers) must request exactly one
extension in the handshake ("deflate-stream"). It does not require that
the server accept it (indeed it notes what happens to the js attributes
if the server does not - interoperation continues without compression)
so I don't think we can fairly say that it makes deflate-stream support
mandatory in anything other than browsers and then only actually use it
when servers acquiesce.

More concerning is that it effectively bans any other transport
extensions in browsers.

This obviously doesn't match the expected use of protocol extensions,
which is a much bigger space than just transport compression. Even if
the RFC contained a perfect deflate-frame which was specified by the
API, it still interacts poorly with mux or anything else that
implementations might want to do at the transport layer. I don't
understand why the JS API is even participating in such a direct way.
(specifying that compression applies to the messages which could be used
to make the decision on what extensions to negotiate would be a more
indirect and at least on the face of it sensible way to go).

There are no changes the IETF WG can make to the ietf-draft that can fix
this mismatch.

As for compression, the most productive thing to do seems to me to be to
define in a separate draft deflate-frame and push it through the
adoption/standardization process. No matter what is defined the
extensions mechanism should (and does!) provide a mechanism for
migration for any sensible protocol implementations.

While I don't want to go to the mat for deflate-stream it certainly has
a number of use cases where it does well - most downstream traffic of >
tiny-sized messages, and large upstream messages - so I'm not in the
camp of "just throw it out".