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

Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> Thu, 08 September 2011 16:39 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 F15C521F8B5B for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 09:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 pyvs+z3Ybeur for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 09:39:45 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6421F8B52 for <hybi@ietf.org>; Thu, 8 Sep 2011 09:39:45 -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; Thu, 8 Sep 2011 09:41:38 -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.339.2; Thu, 8 Sep 2011 09:41:37 -0700
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.161]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0339.002; Thu, 8 Sep 2011 09:40:54 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt
Thread-Index: AQHMaA3rPzNumjQvEUO738RtlvbYEpU4lWeAgAlVZgCAABzOAIAABXSAgAAKlQCAAARCAIAAPaUAgAAdkYCAAZ/agIAAEyAA//+MqnCAAHfmAP//i84Q
Date: Thu, 08 Sep 2011 16:40:54 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C11448BDD3F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> <0fc901cc6878$1681eec0$0a00a8c0@Venus> <CAH9hSJb2rH+fX0AnekYxsEkHKzb15aHrg_hDQw1baWLiWBF-3w@mail.gmail.com> <17b501cc6d31$3016d6d0$0a00a8c0@Venus> <CAH9hSJYhLpcXrOtS-nzLt2YW9QbngEsfdcNF+0TadyVA6rrK1A@mail.gmail.com> <17ef01cc6d39$3575ae50$0a00a8c0@Venus> <20110907085128.GA19144@1wt.eu> <CAH9hSJYXZ285L_+eJh6VUVCAg4D+u=vQbcjVOA4RMsJSbcHqiw@mail.gmail.com> <CABLsOLBKgnTFga821t2AZ1dXobTsfMb5v8CTJhm_Nr8WMkonaA@mail.gmail.com> <53451FDB-77F7-42A1-8D16-05094C35AB5D@bbn.com> <4E68E9F6.6030901@stpeter.im> <CA566BAEAD6B3F4E8B5C5C4F61710C11448BDC88@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1B54A085-1AF4-4324-B252-0C8BE778A69D@bbn.com>
In-Reply-To: <1B54A085-1AF4-4324-B252-0C8BE778A69D@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.42]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.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: Thu, 08 Sep 2011 16:39:47 -0000

> > As chair, I note that the agreement regarding masking (client MUST mask to
> server) was one of the main points behind the VERY hard fought consensus. I
> think this is one of those things we can revisit in version 1.1, along with others
> we've been noting recently.
> 
> I think I understood that consensus slightly differently, more as a capability +
> operational practice than a protocol requirement.  Like I said to John, whatever
> the text says, masking will be appropriate in most cases.

The consensus was clear on the MUST on client to server, so it was a protocol decision, not an operational issue at least at that time.

> > As an individual, the MAY mask on Server to client seems to gain nothing (I'm
> with John Tamplin on this one) and potentially lose something (sendfile), so I'd
> rather say MUST NOT here.
> 
> It doesn't rule out sendfile, since the server can choose not to apply masking.  All
> the proposed text does is clarify that the server has the choice (as it does in the
> current text).

On the server to client, the text is not clear, so I'm not sure it is ok to claim the server can or cannot mask (it is simply not clear).