Re: [hybi] Framing Take VI (a compromise proposal)

John Tamplin <> Mon, 16 August 2010 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11ADF3A67FD for <>; Mon, 16 Aug 2010 08:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.469
X-Spam-Status: No, score=-104.469 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id irhJaiSFMprk for <>; Mon, 16 Aug 2010 08:12:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 551963A69FD for <>; Mon, 16 Aug 2010 08:12:10 -0700 (PDT)
Received: from ( []) by with ESMTP id o7GFCje6025425 for <>; Mon, 16 Aug 2010 08:12:45 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=beta; t=1281971565; bh=rrjnR0d+H0SbLEwiJ0jWWA347i4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tItspsZ5TSfkJNFnbBdQIEIwTWUABdCNX1zwfTs0Ovgc+X3tcs95Aw+2D21XUdpGV S9sNP01VstxamNp/h5sLA==
DomainKey-Signature: a=rsa-sha1; s=beta;; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=cXY2dXGzeOEWZUl4eDZVKgAdZ6q0flZGcN2WvaxF6oUdj1HiYlIPeryxtiMXic+/7 ZH4Vfv7bC3oMGGemvYhnw==
Received: from gyb13 ( []) by with ESMTP id o7GFCXdB010098 for <>; Mon, 16 Aug 2010 08:12:44 -0700
Received: by gyb13 with SMTP id 13so2700383gyb.35 for <>; Mon, 16 Aug 2010 08:12:44 -0700 (PDT)
Received: by with SMTP id a14mr5599699ybf.131.1281971563908; Mon, 16 Aug 2010 08:12:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Aug 2010 08:12:23 -0700 (PDT)
In-Reply-To: <4931.1281970860.071963@puncture>
References: <> <4931.1281970860.071963@puncture>
From: John Tamplin <>
Date: Mon, 16 Aug 2010 11:12:23 -0400
Message-ID: <>
To: Dave Cridland <>
Content-Type: multipart/alternative; boundary=000e0cd6a9b4add675048df24379
X-System-Of-Record: true
Cc: Server-Initiated HTTP <>
Subject: Re: [hybi] Framing Take VI (a compromise proposal)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Aug 2010 15:12:13 -0000

On Mon, Aug 16, 2010 at 11:01 AM, Dave Cridland <> wrote:

> I do reiterate my previous suggestion that the group give serious
> consideration to including a multiplex identifier within the header,
> however, or at least space for one via usage of a reserved bit - I think
> this will help intermediaries cope when we actually get multiplexing going.

The problem is that defining it now basically means deciding how it is going
to be implemented, and I don't think we want to wait until we get such
consensus first.

For example, we might want a multiplexing extension to aggregate multiple
channels' data into a single frame.  So, it might look something like this
(using the idea in the discussion with Greg about extension data):

INI=1/FIN=1 opcode=EXTENDED_FRAME, len=...
  payload: extension type=MUX
      channel 1, FRAME_TEXT, 14 bytes
      channel 14, FRAME_BINARY, 48 bytes
      channel 32, FRAME_TEXT, 1 byte

In that case, you can't have a single channel ID in the header.  So, if we
were to allocate one of the two reserved bits for mux'd frames and defining
the channel id in a fixed place in the header if that bit is set, it would
go unused if we wanted this sort of mux implementation.

The whole reason the agreement to get a base protocol out now and work on
extensions in early 2011 is that we don't have any sort of consensus on how
these extensions should be implemented.  For example, we seem to have pretty
broad agreement that compression should be supported.  However, we have at
least 3 very different ideas for doing it:

   - per-frame compression, using negotiated (and possibly asymmetric)
   algorithms and using a bit per frame to indicate compressed data (and
   possibly exchange compression dictionary information in extension data)
   - mandate zlib compression and manipulate the compression level to avoid
   trying to compress uncompressible data
   - compress the entire stream and flush at each frame boundary, and assume
   uncompressible data won't expand too much

For multiplexing, there appear to be several people on the list who do not
see a need for it at all.  If we want to define mux support in the base
protocol, we not only have to design it now but we have to get consensus
that it should even be included.

John A. Tamplin
Software Engineer (GWT), Google