Re: [hybi] method of allocation of reserved bits to extensions

"Andy Green (林安廸)" <andy@warmcat.com> Fri, 20 May 2011 07:50 UTC

Return-Path: <andy.warmcat.com@googlemail.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 9DF12E06D1 for <hybi@ietfa.amsl.com>; Fri, 20 May 2011 00:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKVilprcNI0t for <hybi@ietfa.amsl.com>; Fri, 20 May 2011 00:50:22 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0DE06B2 for <hybi@ietf.org>; Fri, 20 May 2011 00:50:21 -0700 (PDT)
Received: by bwz13 with SMTP id 13so3227139bwz.31 for <hybi@ietf.org>; Fri, 20 May 2011 00:50:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R/I3WwxdMHYtQFZEg9mif34waBsYKzRMc/rPmBOQjM4=; b=O8AZMZhV3WDyx18s/bI6OOZkStNlKVqfpB5zDRPedTkmhQ0L3jUSBTxPjdGBn0lz66 NgaCQDoi3/A6QLnk15XqWN25O8TfY/MJesfmaXnkcOVDb6iwn0xyDthOWkvA/82Si7Q1 MFhbRQX+7ETjhewiz9u0ggTRUa9c4AxofoFTY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ta5SeTLr6F7teYer2BscWU9fGJhiUld7N5FRgFiGElURu0CnObnUJnrg4nKN3KmJEd Z1ZRiKLYE4Bm5ViN+tTprX90wGC2GBhFM05dhz0UFvU2yx9w5GfxqpTqABK5uILs2xqa MdDN6SghUXKl3dfgcjZ/prdGm8GBqmV1YOO8s=
Received: by 10.204.24.4 with SMTP id t4mr939748bkb.109.1305877820411; Fri, 20 May 2011 00:50:20 -0700 (PDT)
Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 16sm1972553bkm.18.2011.05.20.00.50.17 (version=SSLv3 cipher=OTHER); Fri, 20 May 2011 00:50:18 -0700 (PDT)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4DD61D35.10404@warmcat.com>
Date: Fri, 20 May 2011 08:50:13 +0100
From: "\"Andy Green (林安廸)\"" <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <BANLkTi=vOQDtL5GobitKe8yiUoQFb2go_Q@mail.gmail.com> <BANLkTikaOXg0u+4d8Ly6OxUQ7PFUU=udgQ@mail.gmail.com> <BANLkTikiUkivJitZGU-+q6wBfJ3VW45F8g@mail.gmail.com> <BANLkTindmLQ0KE6K5qUX2ue+=hoLUaznLA@mail.gmail.com> <BANLkTim9w83iSY-TH1yuVAUXxypJk_tmrw@mail.gmail.com> <BANLkTimnMBwNgP_e29exT6dUkp60s2xU3g@mail.gmail.com> <BANLkTi==RTfqaYFT3CQs1pM5Tb501rk2Vg@mail.gmail.com> <BANLkTinqQiMQ4N1vWjyCe682BmdisW-=KA@mail.gmail.com> <BANLkTik1a6CEA8LiiLgsnBt9qHCaybmWfg@mail.gmail.com> <4DBA3809.4010004@oracle.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <BANLkTim8dkW3R2R1ukAqwkXOM0=uqfiPmA@mail.gmail.com>
In-Reply-To: <BANLkTim8dkW3R2R1ukAqwkXOM0=uqfiPmA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>, Hybi <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Brodie Thiesfield <brodie@jellycan.com>, "jg@freedesktop.org" <jg@freedesktop.org>
Subject: Re: [hybi] method of allocation of reserved bits to extensions
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: Fri, 20 May 2011 07:50:22 -0000

On 05/20/2011 07:42 AM, Somebody in the thread at some point said:
> Gabriel
>
> I'm concerned that if we really restrict usage of the reserved bits,
> then we will force extensions into using whole bytes at the start of
> the payload, when they really only want 1 bit.  If we really do get
> into the situation where we have many extensions, then we could have
> many wasted bits.
>
> How about just having a mechanism that if we can allocated as many
> reserved bits as we like, and if more than 3 are allocated then extra
> bytes are prepended to the payload (as needed) for the extra bits.
> Thus we could have unlimited extensions needing unlimited bits.
>
> If a client doesn't want to play that game, then all it need do is
> never handshake with extensions that need more than 3 bits.

Sounds good to me.

This idea of reserved bits being misered is not only unnecessary but it 
is really inefficient - it'll lead to only special, big, connected 
players being able to use them and because they are permanently 
allocated to particular extensions in that model, there will always be a 
desire to withhold them "for later".

Dynamic allocation way anyone can randomly decide their extension will 
use them, no central allocation is needed and multiple extensions using 
reserved bits will always play well (plus or minus other doubts about 
extension ordering not related to reserved bits).

-Andy