[hybi] Proposed Text: Compression

Patrick McManus <mcmanus@ducksong.com> Thu, 09 September 2010 17:24 UTC

Return-Path: <mcmanus@ducksong.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5553A694D for <hybi@core3.amsl.com>; Thu, 9 Sep 2010 10:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level:
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMaPmwb-gEcF for <hybi@core3.amsl.com>; Thu, 9 Sep 2010 10:24:24 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 76BCB3A68EC for <hybi@ietf.org>; Thu, 9 Sep 2010 10:24:24 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id C5B95102A9; Thu, 9 Sep 2010 13:24:51 -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 1A4B210157 for <hybi@ietf.org>; Thu, 9 Sep 2010 13:24:50 -0400 (EDT)
From: Patrick McManus <mcmanus@ducksong.com>
To: hybi <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 09 Sep 2010 13:24:47 -0400
Message-ID: <1284053088.2752.349.camel@ds9.ducksong.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: [hybi] Proposed Text: Compression
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 09 Sep 2010 17:24:28 -0000

We have certainly seen a web evolve where transport time compression of
some document types is a best practice.

http://www.websiteoptimization.com/speed/18/18-2t.html

Local conditions vary of course, and policy of when to transmit
something compressed at this layer should, imo, remain local policy. But
because this is so often a very easy win for the web in general, I
believe websockets ought to provide the mechanism to implement that
policy.

I propose doing this as an extension whose definition is provided in the
base specification. That allows any resource constrained application to
avoid implementing it if they wish. It also provides an existence proof
of an extension which I think is a very important part of the standards
process. 

I think an implementation which negotiates this "on" and then compresses
every text message over 125 bytes makes some sense - but an
implementation is free to do whatever it wants, of course.

The text below does not address the negotiation of the extension - that
is presumably part of the handshake and that is still in a confused
state which I don't help resolve here.

My text presumes this will be section 8 and the current 8->N will be
+1'd.

...

8. Known Extensions

Extensions provide a mechanism for implementations to opt-in to
additional protocol features. This section defines the meaning of
well-known extensions but implementations may use other extensions as
well.

8.1. Compression

The registered extension token for the compression extension is "gzip". 

The compression extension does not have any extension data. It uses the
RSV1 bit of the frame header to indicate compression, and it MAY be
combined with any other extension that does not use the RSV4 bit.

All frames of a message MUST have the same RSV1 value.

Compression is applied to the Application Data portion of the message
using the gzip encoding as defined by RFC 1952. The application data
length of a compressed frame represents the length of the compressed
data payload. 

...