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

John Tamplin <jat@google.com> Tue, 31 May 2011 21:58 UTC

Return-Path: <jat@google.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 AC10BE070C for <hybi@ietfa.amsl.com>; Tue, 31 May 2011 14:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level:
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UczWghbpbXp for <hybi@ietfa.amsl.com>; Tue, 31 May 2011 14:58:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 124D1E06B5 for <hybi@ietf.org>; Tue, 31 May 2011 14:58:28 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p4VLwSYr001796 for <hybi@ietf.org>; Tue, 31 May 2011 14:58:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306879108; bh=p9EemY5YWm4ewCVNKKqrM3XDnUg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZI1KwZcHZrJBFEaOxKgS/YffKYhizUQpHaH2PjEv/9ivxZSNG4mN9T5G/pZzUu2Pt Mp555PQi/Hfx5ehD0LDHA==
Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by wpaz5.hot.corp.google.com with ESMTP id p4VLvZUJ008950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 31 May 2011 14:58:27 -0700
Received: by gyf2 with SMTP id 2so2873015gyf.11 for <hybi@ietf.org>; Tue, 31 May 2011 14:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1ERHtaXtSNwyfYqGMr82h582KUnAjc5CdKIZd44QTJ4=; b=mSosq+A+98t3TCrF7HvHWfM6Jqniy2nMHsK5rfkKmnP0R+yqAH9TEWF7SZG9Qk8o17 LPhHc6xR2lS3AVQ2aiLg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=nmdfHsdQi8a1+i7FYSOp3jcXryQa7GWAsSeqzSxqYKY85os6x+z2zj7rLhT4m96a4o Cws9MXAIIYlC/+NUJ2nA==
Received: by 10.151.5.15 with SMTP id h15mr5376700ybi.2.1306879107174; Tue, 31 May 2011 14:58:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.49.7 with HTTP; Tue, 31 May 2011 14:58:07 -0700 (PDT)
In-Reply-To: <BANLkTimT=hgop617WmhC+iijqWg80Q2ucw@mail.gmail.com>
References: <BANLkTinqQiMQ4N1vWjyCe682BmdisW-=KA@mail.gmail.com> <BANLkTik1a6CEA8LiiLgsnBt9qHCaybmWfg@mail.gmail.com> <4DBA3809.4010004@oracle.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <cbutt65hgt3ujdbi9jqa3v9a42iigglldk@hive.bjoern.hoehrmann.de> <CA566BAEAD6B3F4E8B5C5C4F61710C11402F796C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <BANLkTimT=hgop617WmhC+iijqWg80Q2ucw@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Tue, 31 May 2011 17:58:07 -0400
Message-ID: <BANLkTimn3vcjuk3fSW=zY6ZpAfRMt1c0vw@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary="000e0cd489f6f2938104a4998010"
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Bjoern Hoehrmann <derhoermi@gmx.net>
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: Tue, 31 May 2011 21:58:29 -0000

On Tue, May 31, 2011 at 5:52 PM, Greg Wilkins <gregw@intalio.com> wrote:

> I was thinking that the extra text was not so much trying to enforce
> IANA rules/exclusions.  More to remind the developers that extra data
> can be added to the payload for extra op-codes and flags.  Ie reduce
> the temptation to squat on the reserved bits by steering them to an
> acceptable alternative.
>

I disagree with using existing opcodes for something different -- if a frame
is labelled as binary, then it should represent binary payload data that
will be delivered to the app.  If you want to have the payload that means
something else, then it needs a different opcode.  Even if you allowed
hijacking the existing frame definitions, it seems like you still have the
same problem in assigning values for the "secondary opcode" stored in the
first byte.

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