IETF Logo Mail Archive

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

Joel Martin <hybi@martintribe.org> Thu, 08 September 2011 16:35 UTC

Return-Path: <buskanaka@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 4613021F899F for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 09:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 2Pzx3xizKuHo for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 09:35:17 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C621F8782 for <hybi@ietf.org>; Thu, 8 Sep 2011 09:35:17 -0700 (PDT)
Received: by fxe6 with SMTP id 6so1828072fxe.31 for <hybi@ietf.org>; Thu, 08 Sep 2011 09:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=rjGFYH8mIOwyCfrvpFSKLolII43GL7JI3uuTIH+W0j0=; b=lLhx6zjz+RNkiqNTdMr5673GZqsi/cr0t1++1rWZMKAMnnFCcVZei02ICeqUXVrh35 R88SeJDBGlmyiFHp2ZKR8GY0A0UBUV1c3xvw0pdWo+Bcrsq3sTdWl+q4ka3JhstH0Yuy vE26bDn2hOEBC6Awq0WJZMJPkdaNFm2kwsloU=
Received: by 10.223.28.10 with SMTP id k10mr457037fac.128.1315499828084; Thu, 08 Sep 2011 09:37:08 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.223.96.71 with HTTP; Thu, 8 Sep 2011 09:36:48 -0700 (PDT)
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11448BDC88@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>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 08 Sep 2011 11:36:48 -0500
X-Google-Sender-Auth: TFbFxxzPYmfAYjED6bRejJz1WRM
Message-ID: <CAO228NuU26y2PkViwqr6DAgJ2v5X-f6c4KZiTs6iQKdK=fW2Vw@mail.gmail.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Content-Type: multipart/alternative; boundary="00151743f874f47e3f04ac70ab44"
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:35:18 -0000

On Thu, Sep 8, 2011 at 11:24 AM, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> wrote:

> 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.
>
> 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.


I concur. Client to server MUST mask. Server to client MUST NOT mask. Server
MUST fail unmasked messages from the client.

I would also be okay with adding a note indicating that in a future revision
of the spec, when WebSockets is used with clients that are running trusted
code (i.e. not browsers), the client may choose to not mask and the server
can accept unmasked frames. But I think this should only be a note to
indicate possible future direction.

Joel Martin

v2.23.0 | Report a Bug | By Email