[hybi] Compression spec decoupling

Takeshi Yoshino <tyoshino@google.com> Thu, 26 April 2012 04:24 UTC

Return-Path: <tyoshino@google.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 DDBFC21F8897 for <hybi@ietfa.amsl.com>; Wed, 25 Apr 2012 21:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.921
X-Spam-Level:
X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3W3d4Z7HSIw for <hybi@ietfa.amsl.com>; Wed, 25 Apr 2012 21:24:09 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9511E8085 for <hybi@ietf.org>; Wed, 25 Apr 2012 21:24:09 -0700 (PDT)
Received: by lagj5 with SMTP id j5so662670lag.31 for <hybi@ietf.org>; Wed, 25 Apr 2012 21:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=uAgiQ170EVYQhFAxb+UTsP8nViUvKfcmM3rm3oJlXag=; b=nbsAPq+kQB7XuX8AAumpOqdhntOPZaWjMt0zE5qFXmXvaI+HHX6WqBc7Vwbed5c3Xh KadHsDRjThZynyswUMKdy2MTuAgBH/k+0GmiUcPury2MNiYpsVqYTmfUOd8XHPaVlXii GNZc1Ux3g+Pp2MOazgr+DnIXOYBde4LDBxwOQOWkj4VCp1vdnnuT3Z+9L0qZMl1xAUvS 72C2RiXZAJ3pXZ6KdmIJl3Sx6rJ4wRoy3MqslVS2V/2+pm6UuwHAQVHXf8PhEWNuTETH nrFyiykP7wI4zCMzxeRvGo4pSOeO04wwQEHT9IEdOfxswtWyktNbUHGULDQCyK9Lgz24 nDXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=uAgiQ170EVYQhFAxb+UTsP8nViUvKfcmM3rm3oJlXag=; b=c5J2qkfXpQTAwr4nfOC8fe2POGOdPbBFW4CA8oa+sOkey6C1io3z2HlDdB2PGNx7v2 zfJgImQEl8Bl7ZeosXdV6WWqIj4l/6AytLarxwphNyjOz1V79CyOkPU3v+xQnCmH7zQB HMNxFrnuoADGA3Yk6F6YVjef/xWqq1K1KFfvfuDnMJhhxMqIMvwCmn7zOymBmJPfLYy6 Z7dxhLhU83EUsKKl6Yybf2LIP0XKldht6WPR+B5xctDf12fdBUqw6Serl3AnbMcPiGaf X2z3VraKWt7XuWsp5Uypg//ax1LgtJsIRIwcyFQhvuQja0hL8OCDdvX1KjqB7gg9kQXj MygA==
Received: by 10.112.29.99 with SMTP id j3mr1975262lbh.47.1335414247905; Wed, 25 Apr 2012 21:24:07 -0700 (PDT)
Received: by 10.112.29.99 with SMTP id j3mr1975252lbh.47.1335414247770; Wed, 25 Apr 2012 21:24:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.48.165 with HTTP; Wed, 25 Apr 2012 21:23:47 -0700 (PDT)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 26 Apr 2012 13:23:47 +0900
Message-ID: <CAH9hSJbr1rXvda87NrHO91JMe5nhM_cHaRODAsSWW-io_9iZJw@mail.gmail.com>
To: hybi@ietf.org, John Tamplin <jat@google.com>, Arman Djusupov <arman@noemax.com>, Greg Wilkins <gregw@webtide.com>
Content-Type: multipart/alternative; boundary="f46d040167e3ddca3904be8d5b3a"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQm9DrRxm++UApI2qY1EB7unv0ivqdyGjBxKQ+MnWxqXfRKYWjHwwVrX6/PetxVcqYT2I1pDmmG8UUVIfRtgH/T8sYkCw2tK8jG6dUACZCuhMtHhMOqDumPBtlhQfyGD9oQthUrj
Subject: [hybi] Compression spec decoupling
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: Thu, 26 Apr 2012 04:24:11 -0000

As the target data is close, I'd like to list options with concrete
examples and call for opinions to settle this topic.

See also this thread:
http://www.ietf.org/mail-archive/web/hybi/current/msg09469.html

We have two options.
(I saw slight objection to add a new handshake header to pass
algorithm parameter in f2f meeting)

a) One per-frame compression extension for all compression algorithm

draft-ietf-hybi-websocket-perframe-compression defines
- an extension "perframe-compress" and how it frames data including usage
of RSV1
- an extension parameter "algorithm" and its format
- an algorithm parameter "deflate" and how it transforms data

RSV1 is given to perframe-compress extension. It might make incompatible
extension checking easier.

There something does "per-frame compression" but needs framing beyond what
we define in this spec might come in the future. Then, we need to choose
either of break this 1:1 assignment or forbid it to use RSV1.

Example:
Sec-WebSocket-Extensions: perframe-compress; algorithm="foo;
foo-param1=123, bar; bar-param1=abc"; general-param1=xyz", ...

Example (with mux):
Sec-WebSocket-Extensions: perframe-compress; algorithm="... (algorithms for
pre-mux) ...", mux, perframe-compress; algorithm="... (algorithms for
post-mux) ..."

b) One extension for each per-frame compression algorithm

draft-ietf-hybi-websocket-perframe-compression defines
- a method how to frame data with per-frame compression including usage of
RSV1
- an extension "deflate-frame" which uses the framing method and how to
transforms data

RSV1 is given to any extension that does per-frame compression. Endpoints
need to sort out mutually exclusive extensions.

Any future per-frame compression extension may or may not refer to the
framing method defined in draft-ietf-hybi-websocket-perframe-compression.

Example:
Sec-WebSocket-Extensions: foo-compress; foo-param1=123, bar-compress;
bar-param-1=abc, ...

Example (with mux):
Sec-WebSocket-Extensions: ... (extensions for pre-mux) ...", mux, ...
(extensions for post-mux) ..."