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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 09 September 2011 00:33 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 E3E5421F8BF8 for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 17:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.747
X-Spam-Level:
X-Spam-Status: No, score=-99.747 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 8h63LyI5NUEr for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 17:33:54 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 46D2121F8BF0 for <hybi@ietf.org>; Thu, 8 Sep 2011 17:33:53 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p890Zaw5008826 for <hybi@ietf.org>; Fri, 9 Sep 2011 09:35:36 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 49b0_12bb_a2de6bbc_da7b_11e0_9c2b_001d096c566a; Fri, 09 Sep 2011 09:35:36 +0900
Received: from [IPv6:::1] ([133.2.210.1]:47486) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S154BAB1> for <hybi@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 9 Sep 2011 09:35:39 +0900
Message-ID: <4E695F4E.1080606@it.aoyama.ac.jp>
Date: Fri, 09 Sep 2011 09:35:26 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Gabriel Montenegro <Gabriel.Montenegro@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> <CA566BAEAD6B3F4E8B5C5C4F61710C11448BDD3F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11448BDD3F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 09 Sep 2011 00:33:55 -0000

On 2011/09/09 1:40, Gabriel Montenegro 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.
>>
>> 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.

I agree with this, and I hope we can move on quickly and not have 
another long discussion on masking.

However, just for the record, I would want to point out that the way the 
browser maker people explained their strong desire for masking was "if 
ever something bad happens, it's always the browser which is blamed". 
That seems to indicate that the guys in charge of performing masking 
from the client side (e.g. the browser makers) and the guys interested 
in having it done are the same. In such a case, changing a MUST to a 
SHOULD is much less of a problem than when the SHOULD is there to 
protect somebody else's interest.


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

Whichever way, this definitely should be clarified.

Regards,   Martin.