Re: [hybi] frame length encoding

John Tamplin <jat@google.com> Sun, 22 August 2010 15:44 UTC

Return-Path: <jat@google.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 2394D3A68F8 for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 08:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.236
X-Spam-Level:
X-Spam-Status: No, score=-105.236 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 8ReHpy8fLc7y for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 08:44:02 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BC2A43A68F6 for <hybi@ietf.org>; Sun, 22 Aug 2010 08:44:01 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o7MFiZ9M019823 for <hybi@ietf.org>; Sun, 22 Aug 2010 08:44:35 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282491875; bh=bdSY/BgAeZKNZ1/jixe6Kw0RRWk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CWwHetNw/5IZ2UXOvf+N5Ln4TzKqIimPGByIqizR6/g4H17eLHC7cVyFLEpiN5HWf zQStg7DQdZj59t2W0nH3g==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; 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=Q95PH8Nsh3eRrw2Jbc6uRflcJmmDpZx9u/Is/gdgM1KdgQem27PwdnmdR/IWAWXMY U1QpZ9IRXiw4b+rMmbhlQ==
Received: from gwj19 (gwj19.prod.google.com [10.200.10.19]) by hpaq14.eem.corp.google.com with ESMTP id o7MFiXIh026810 for <hybi@ietf.org>; Sun, 22 Aug 2010 08:44:33 -0700
Received: by gwj19 with SMTP id 19so2496385gwj.35 for <hybi@ietf.org>; Sun, 22 Aug 2010 08:44:33 -0700 (PDT)
Received: by 10.151.158.16 with SMTP id k16mr1073227ybo.387.1282491873126; Sun, 22 Aug 2010 08:44:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.60.3 with HTTP; Sun, 22 Aug 2010 08:44:12 -0700 (PDT)
In-Reply-To: <866afa4e2398b2c0aeafd7b281d95f05.squirrel@sm.webmail.pair.com>
References: <AANLkTimKbmcpgx8k0uXUWvCO=8w9pPrtV=3y4qh6363k@mail.gmail.com> <alpine.DEB.2.00.1008212037190.27211@tvnag.unkk.fr> <AANLkTinrsT+wV48nHvVW_1ChGYffkq7jisU2-PZnMyKg@mail.gmail.com> <alpine.DEB.2.00.1008212123460.27211@tvnag.unkk.fr> <20ef7ed5e135c57c1ee5a741658b9d98.squirrel@sm.webmail.pair.com> <1282423311.2014.6.camel@tng> <224b9ed365bd78fd5e316b8cb5f3f837.squirrel@sm.webmail.pair.com> <1282435214.2014.14.camel@tng> <AANLkTimo0MwZEMn1t1vrASfwC1bx82Q9Z_Ls3wVb-zUS@mail.gmail.com> <b95f074b65875865802f532bb5668ff2.squirrel@sm.webmail.pair.com> <866afa4e2398b2c0aeafd7b281d95f05.squirrel@sm.webmail.pair.com>
From: John Tamplin <jat@google.com>
Date: Sun, 22 Aug 2010 11:44:12 -0400
Message-ID: <AANLkTi=sBncatpYohtugTKY_7OVgh2K+9j=p45c9btK_@mail.gmail.com>
To: shelby@coolpage.com
Content-Type: multipart/alternative; boundary="001517510dda866c4f048e6b688b"
X-System-Of-Record: true
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] frame length encoding
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: Sun, 22 Aug 2010 15:44:03 -0000

On Sun, Aug 22, 2010 at 5:53 AM, Shelby Moore <shelby@coolpage.com> wrote:

> I forgot that I had already mentioned in this thread that we only need to
> keep 1 reserved bit free, so that we can always add another bit as needed,
> by allocating that 1 bit to signal there is an extra byte.  Repeat in next
> byte, and so on...
>
> So we don't need the extra byte now, unless we see an extension now that
> needs that many bits.
>
> Any one disagree?


Yes, I agree that as long as we don't use our last reserved bit for
something besides "more reserved bits", we can arbitrarily extend the
protocol.  However, we have several things which we know we want to
implement as extensions in short order - multiplexing and compression among
them, and perhaps additional metadata.  If we only have one spare bit in the
base protocol, then that means we must define it as the "more reserved bits"
flag, and we will then be paying a cost for what are expected to be common
extensions.  Also, note that we would have to negotiate adding these
reserved bytes in the handshake for interoperability with base protocol
implementations.

-- 
John A. Tamplin
Software Engineer (GWT), Google