Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt

Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> Tue, 14 June 2011 22:43 UTC

Return-Path: <Gabriel.Montenegro@microsoft.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 D6D7711E8153 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 15:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.161
X-Spam-Level:
X-Spam-Status: No, score=-10.161 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 WgZ+VU-5jVCj for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 15:43:43 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4869511E811E for <hybi@ietf.org>; Tue, 14 Jun 2011 15:43:43 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 14 Jun 2011 15:43:42 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 14 Jun 2011 15:43:42 -0700
Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Tue, 14 Jun 2011 15:43:41 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>, "Patrick McManus" <pmcmanus@mozilla.com>
Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
Thread-Index: AQHMKiMqAJa2fRic6UyXwsa0KTbkfpS83EkAgACF24CAACi7AIAAEdQAgAAIBoD//8iK4A==
Date: Tue, 14 Jun 2011 22:43:41 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com>
In-Reply-To: <4DF7A9ED.3000609@warmcat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
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, 14 Jun 2011 22:43:43 -0000

The 07 version had no explicit behavior defined, but if any bits or opcodes were used unexpectedly, something was obviously very wrong:

07:
   As such, in the absence of extensions negotiated during the opening    
    handshake (Section 5), all reserved bits MUST be 0 and reserved     
    opcode values MUST NOT be used.

08 had to resolve what to do with RSV bits and opcodes, so it introduced behavior to ignore:

08:
For RSV bits: " the receiving endpoint MUST ignore that value."
Opcode: " receiving endpoint MUST ignore that frame"

In some discussion with Alexey, Ian and the chairs, it seemed like the behavior to introduce should be to abort the connection, in line with something being very wrong. 09 was supposed to reflect that, but as you point out, it only does that half way:

09:
For RSV bits: " receiving endpoint MUST _Fail the WebSocket  Connection_. "
Opcode: no change from 08: ignore that frame

The intent was to have Opcode also say " receiving endpoint MUST _Fail the WebSocket  Connection_" given that something is very wrong anyways.

Whatever it is, it is best if both RSV and Opcode are handled the same way (either always fail the connection or always ignore)

Does this clarify? Do folks agree that revising to failing in both cases is fine? 

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> "Andy Green (???)"
> Sent: Tuesday, June 14, 2011 11:35
> To: Patrick McManus
> Cc: hybi@ietf.org
> Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
> 
> On 06/14/2011 07:06 PM, Somebody in the thread at some point said:
> >
> > On Tue, 2011-06-14 at 10:02 -0700, Ian Fette (イアンフェッティ) wrote:
> >> There was an email to the chairs pointing out that unknown values in
> >> reserved bits vs unknown opcode values were handled differently. The
> >> chairs discussed and asked me to make them both fail.
> >>
> >
> > I'm confused.
> >
> > In -08 an unknown RSV* mandates a MUST ignore, and an unknown opcode
> > also mandates a MUST ignore. That seems like a match to me.
> >
> > In -09 unknown RSV* mandates a FAIL, and unknown opcode mandates an
> > ignore.
> >
> > how does that mesh with what was done?
> 
> I guess it can make sense, the opcode has a length so you can skip it okay even if
> you don't understand what's inside.
> 
> But RSV bits might mess with the framing so you can't interpret the length
> correctly any more, you're dead in the water then for skipping it.
> 
> -Andy
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi