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

Greg Wilkins <gregw@intalio.com> Thu, 28 April 2011 03:04 UTC

Return-Path: <gregw@intalio.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 C6D27E06AE for <hybi@ietfa.amsl.com>; Wed, 27 Apr 2011 20:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.939
X-Spam-Level:
X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Wg6tiz6D2IXs for <hybi@ietfa.amsl.com>; Wed, 27 Apr 2011 20:04:21 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E1518E0675 for <hybi@ietf.org>; Wed, 27 Apr 2011 20:04:20 -0700 (PDT)
Received: by qyk7 with SMTP id 7so1255331qyk.10 for <hybi@ietf.org>; Wed, 27 Apr 2011 20:04:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.102.86 with SMTP id f22mr2408081qco.28.1303959860156; Wed, 27 Apr 2011 20:04:20 -0700 (PDT)
Received: by 10.229.186.9 with HTTP; Wed, 27 Apr 2011 20:04:20 -0700 (PDT)
In-Reply-To: <BANLkTindmLQ0KE6K5qUX2ue+=hoLUaznLA@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>
Date: Thu, 28 Apr 2011 13:04:20 +1000
Message-ID: <BANLkTimB+TZGb1AVgbRdMf1ZkK+Cy2Gumw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.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>
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: Thu, 28 Apr 2011 03:04:21 -0000

On 28 April 2011 12:13, John Tamplin <jat@google.com> wrote:
> reserved bits, it seems reasonable to simply define that the Foo extension
> allocates RSV2.  If another extension also statically allocates RSV2, then
> obviously they couldn't be used together.

It might be reasonable if you are google, as you will have the market
share such that any decision you make to allocated a reserved bit for
your own extensions will effectively allocate that bit to you forever.

Imagine I'm an intermediary vender and I develop a private extension
for my WS aggregator to talk to the servers behind it that uses a
reserve bit.    If google chrome subsequently comes out with a very
popular extension that uses the same reserved bit, then my
intermediary product will have been badly impacted.  I will either
have to redeploy all my intermediaries using another reserved bit or
lose market share because I don't support googles latest extension.

it is not a level playing field.