[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. ...
- [hybi] Proposed Text: Compression Patrick McManus
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Patrick McManus
- Re: [hybi] Proposed Text: Compression Brian Smith
- Re: [hybi] Proposed Text: Compression Dave Cridland
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Patrick McManus
- Re: [hybi] Proposed Text: Compression Greg Wilkins
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Dave Cridland
- Re: [hybi] Proposed Text: Compression Greg Wilkins
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Dave Cridland
- Re: [hybi] Proposed Text: Compression Patrick McManus
- Re: [hybi] Proposed Text: Compression Hector Santos
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Joe Hildebrand
- Re: [hybi] Proposed Text: Compression Patrick McManus
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Self Disconnect
- Re: [hybi] Proposed Text: Compression Benjamin Black
- Re: [hybi] Proposed Text: Compression Joe Hildebrand
- Re: [hybi] Proposed Text: Compression John Tamplin
- Re: [hybi] Proposed Text: Compression Hector Santos
- Re: [hybi] Proposed Text: Compression Benjamin Black
- Re: [hybi] Proposed Text: Compression Greg Wilkins
- Re: [hybi] Proposed Text: Compression Patrick McManus
- Re: [hybi] Proposed Text: Compression Greg Wilkins
- Re: [hybi] Proposed Text: Compression Patrick McManus