IETF Logo Mail Archive

Re: [hybi] RSV bits in extensions

Jonathan Castello <twisolar@gmail.com> Mon, 21 May 2012 11:15 UTC

Return-Path: <twisolar@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 1E82D21F85E6 for <hybi@ietfa.amsl.com>; Mon, 21 May 2012 04:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh5jhxOcWp2W for <hybi@ietfa.amsl.com>; Mon, 21 May 2012 04:15:21 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9221F85E3 for <hybi@ietf.org>; Mon, 21 May 2012 04:15:21 -0700 (PDT)
Received: by yhq56 with SMTP id 56so5016115yhq.31 for <hybi@ietf.org>; Mon, 21 May 2012 04:15:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=y1E4zOU5OybxUpIeyndNpDtCNOsoMuc9AiKrti2Lj3Y=; b=0dE+q25rQCOBulztSLYneQTL33V8KQces7Mrz9nfpQore9hKXeGqza7sDBCWbZYL9B KY3NmZGWUvRkZUI3yHS36vuy6tD3k/44vPdVqosgH9WG0hsvzhQiRcQcSToWn/0VajE7 9AD+o65Yfgc8oTUiEH1HpEb9AEIvMUhw2PdKTwq4zSROE3Txm/eP8q+2afnbkwYxMQXr IVF71BvnaYuyk1ByAB8WBttksLLy8AAWeF0NXO21bvnSoks2m+kO7ZlduR6MfGs9+HGy KdQZGQdQLDterkX/IzprFSGXrmRF7kIH3zDAy/FS0/jq97egQlBIq6QS6AK6yfatNN/k E8Qg==
Received: by 10.50.222.200 with SMTP id qo8mr6296725igc.20.1337598920456; Mon, 21 May 2012 04:15:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.94.226 with HTTP; Mon, 21 May 2012 04:14:50 -0700 (PDT)
In-Reply-To: <CAH_y2NECM4Cx+C3f_uqg+-CgJ1QLgfaf8Gxp6ha4bc5nToKcKg@mail.gmail.com>
References: <D212E3B5-0DB8-4F52-B16F-A4B5D89F932E@zaphoyd.com> <CAH9hSJZxCcntP6SCL176jcEi_2b_EfYLhhnHE25t9fr1KGb5gw@mail.gmail.com> <CAH_y2NECM4Cx+C3f_uqg+-CgJ1QLgfaf8Gxp6ha4bc5nToKcKg@mail.gmail.com>
From: Jonathan Castello <twisolar@gmail.com>
Date: Mon, 21 May 2012 04:14:50 -0700
Message-ID: <CALxFSDB=e7OKE-379Ou1aoF9S6_110HtMF=xg6Qs0CYsY_n_0A@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>, Peter Thorson <webmaster@zaphoyd.com>
Subject: Re: [hybi] RSV bits in 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: Mon, 21 May 2012 11:15:22 -0000

On the other hand, an extension could allocate an RSV bit only for
specific opcodes. If per-frame compression was only defined on text
and binary frames, RSV1 could be used by another extension on other
opcodes. This kind of scoping less solves the problem than it does
push it to the number of available opcodes, but it is an option.

Incidentally, this is my first message to the list. Hello!

~Jonathan Castello

On Mon, May 21, 2012 at 3:35 AM, Greg Wilkins <gregw@intalio.com> wrote:
> In practise, I believe this means that the RSV bits are of very very limited
> use to 3rd party extensions and really have  been reserved for extensions
> developed by this WG.    For example RSV1 will effectively become the
> compression bit once the per-frame-compession draft is accepted and RSV1
> will only be able to be used by other extensions that are obviously mutually
> exclusive to per-frame-compression (such as stream compression)
>
> I'm not saying this is a bad thing... it's probably good to have these bits
> available for standard extensions without the need for the complexity of
> dynamic bit allocations.     It just means that 3rd party extension should
> really avoid using these bits and put their own flags in the payload....
> unless somebody wants to define the unlimited-reserved-bit extension to be
> used with other extension :)
>
> cheers
>
>
>
> On 21 May 2012 09:46, Takeshi Yoshino <tyoshino@google.com> wrote:
>>
>> On Sat, May 12, 2012 at 2:24 AM, Peter Thorson <webmaster@zaphoyd.com>
>> wrote:
>>>
>>> Is the intention of the RSV registration to prevent the reuse of RSV bits
>>> or simply to catalog their use and help determine potential conflicts?
>>
>>
>> My understanding is
>> - it's to get the allocation widely known to prevent unexpected
>> confliction, complication.
>> - it doesn't disallow use of the same bit by multiple extensions
>> completely.
>>
>>>
>>> In the case that an endpoint gets a handshake request for two extensions
>>> with incompatible RSV bit registrations what is the expected behavior? Just
>>> pick one? Return an incompatible extension code? Return protocol error?
>>> Something else?
>>
>>
>> I think
>> - it's ok to request two or more mutually incompatible extensions
>> - it's ok that the server accept the client by picking one of them.
>> - if the client requested two or more mutually incompatible extensions and
>> the server acked two or more of them, the client must fail.
>>
>> Takeshi
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

v2.23.0 | Report a Bug | By Email