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

Brodie Thiesfield <brodie@jellycan.com> Wed, 25 May 2011 03:18 UTC

Return-Path: <brofield@gmail.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 48D07E0751 for <hybi@ietfa.amsl.com>; Tue, 24 May 2011 20:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BcXLVWovOVYf for <hybi@ietfa.amsl.com>; Tue, 24 May 2011 20:18:55 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC28BE0682 for <hybi@ietf.org>; Tue, 24 May 2011 20:18:55 -0700 (PDT)
Received: by pzk5 with SMTP id 5so4336759pzk.31 for <hybi@ietf.org>; Tue, 24 May 2011 20:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fz3Pu5lxy7cob4WejZDpa+gm1l6x4ZCK+43KkmzK9Tc=; b=atEvfVbyyG2PH6+5/7d5WJBlX3nQNPIDtxF5tYTnjPRIzavSlBrZt8Lvq2FTTkqa2Q s9McyX4BEMoT9c+xO2Fv427pBsbQdDZB3U+hYcj4fh/siNvNBJuWet2ng6spS1fk1Jja l2U6CH+fQoXAGewlqDlZVezQhD/7vI+S2OEus=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hucVlpiLqbO0CwIhytCFfdoIO/i8W1YLotR4sXUQwzGUkikaGVWh9JjSfjJmNrqHWR qJx9gPRMkQ47+H5SyLuE4UB9Ooy/M1f8cNsnfCDX0/x0vej64SqvAe5btolCpTku0Ran E49TpCHLPz9fmpVYtXdCQmPhh2rEjo42Nxpno=
MIME-Version: 1.0
Received: by 10.68.22.2 with SMTP id z2mr3117042pbe.428.1306293535431; Tue, 24 May 2011 20:18:55 -0700 (PDT)
Sender: brofield@gmail.com
Received: by 10.68.40.134 with HTTP; Tue, 24 May 2011 20:18:55 -0700 (PDT)
In-Reply-To: <BANLkTikwysTjCw62aZSi_3faHrQjYW=fuw@mail.gmail.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> <4DD61D35.10404@warmcat.com> <BANLkTi=57EYWnuOv3n=crHsgC5t3x=PPkA@mail.gmail.com> <BANLkTi=hP1CPNE+3PSHUTWcBHW_WPxCBQw@mail.gmail.com> <BANLkTikwysTjCw62aZSi_3faHrQjYW=fuw@mail.gmail.com>
Date: Wed, 25 May 2011 12:18:55 +0900
X-Google-Sender-Auth: 6SiQ0771NXG0zMZL2pRE9_6qjEc
Message-ID: <BANLkTiku1qznAK-yv4jUdfpuRVfuaBD7Hg@mail.gmail.com>
From: Brodie Thiesfield <brodie@jellycan.com>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>, Alan Coopersmith <alan.coopersmith@oracle.com>, "jg@freedesktop.org" <jg@freedesktop.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Greg Wilkins <gregw@intalio.com>
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: Wed, 25 May 2011 03:18:56 -0000

On Wed, May 25, 2011 at 12:04 PM, John Tamplin <jat@google.com> wrote:
> On Tue, May 24, 2011 at 10:40 PM, Greg Wilkins <gregw@intalio.com> wrote:
>>
>> The simplest solution is to say that the 3 bits (and spare opcodes) in
>> the framing are reserved for future versions of the protocol - ie off
>> bounds to all extensions.
>>
>> ....snip...
>>
>> The only outcome I'm strongly against is the status quo - where we
>> have a few scarce resources with no fair share mechanism defined.
>> This will just result in unfair market forces being used to make
>> defacto allocations of those bits (and opcodes for that matter).   It
>> is better not to have them than to have them with no fair share
>> policy.
>
> So why do you object to leaving it up to the definition of the first
> extension that wants to allocate a reserved bit?  At that point, it could
> define the dynamic allocation method you want.  It isn't like any one party
> can railroad through a standards definition allocating one or more of the
> bits.  I don't object to the idea, but I do not want to hold up the base
> spec, which isn't going to define a use for these bits anyway, trying to get
> consensus on how they should be allocated (though personally my preference
> is a registry rather than the complexity of dynamically allocating them).

Then making them reserved and off-limits to arbitrary use by
extensions, and requiring the use of the IANA registry is your
preference as well?

> It sounds to me like you are saying "if I can't have it my way, nobody can
> have them".  If they can't ever be used for extensions, it isn't entirely
> clear what they could be used for, so we would be better off just allocating
> them to the opcode than leaving them unused.

If they are registered it doesn't mean they can't be used. Just that
the extension that uses them must be blessed with the registration.
All other extensions just add a byte to their payload and use it for
their flags.

Regards,
Brodie