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

"Len Holgate" <len.holgate@gmail.com> Thu, 01 September 2011 07:22 UTC

Return-Path: <len.holgate@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 3D9A521F84C5 for <hybi@ietfa.amsl.com>; Thu, 1 Sep 2011 00:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ni+XJOeMKI0t for <hybi@ietfa.amsl.com>; Thu, 1 Sep 2011 00:22:18 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0212E21F8581 for <hybi@ietf.org>; Thu, 1 Sep 2011 00:22:16 -0700 (PDT)
Received: by wwf5 with SMTP id 5so1047947wwf.13 for <hybi@ietf.org>; Thu, 01 Sep 2011 00:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=q5m75+kS6eCb95c376ADSMQiD4fIPBgsCv9e6a+/2jo=; b=JQ7h5q7IdpKiPm4HBiAwfxww9V7Ce20QRW8oZ72+9R9nhC1pV7NX2DQuzfQWiv3Sjn 2D0LtTH3ZrRCxbmlH20Pb4lQDsYUP3HVyK0vhF4sxnRGKRMFPD6vlR9GYm1ubguFNzt3 Yyh73YJnWyARRS5nLGzQy13/8FALymXtYIUqU=
Received: by 10.216.18.130 with SMTP id l2mr461927wel.74.1314861828180; Thu, 01 Sep 2011 00:23:48 -0700 (PDT)
Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id i51sm177240wed.19.2011.09.01.00.23.46 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 00:23:47 -0700 (PDT)
From: Len Holgate <len.holgate@gmail.com>
To: hybi@ietf.org
References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com>
Date: Thu, 01 Sep 2011 08:23:45 +0100
Message-ID: <0fc901cc6878$1681eec0$0a00a8c0@Venus>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20110831184207.1514.64093.idtracker@ietfa.amsl.com>
Thread-Index: AcxoDeyV33px3ztrTleq1zMqI6+5BwAYZIcw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
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, 01 Sep 2011 07:22:19 -0000

Nit picking, but...

 4.2.1 step 6 should probably say "value of 13".

 Why doesn't 5.1 use MUST and MUST NOT when talking about client to server
and server to client masking. Up until now I was under the impression that
the server COULD mask data if it really wanted to (hence the need for the
masking bit rather than simply assuming that client -> server == masked and
server -> client != masked. The text in 5.1 now seems to imply that the
server SHOULD NOT mask but it doesn't say so. I realise that client ->
server masking is required and is specified with MUST in another part of the
document but I think it should be made clear that a server CAN mask if it
really wants to so that we don't end up with client implementations that
don't expect to receive masked frames. One situation where I might wish to
mask a frame from server to client would be in a pong where there's no need
for me to unmask the data if I simply echo the ping directly back...

Apart from that I think this draft addresses all of the issues that I
considered important and I like the additional text that explains why the
spec is as it is.

The result is a much better document than I was expecting when I first
started to take an interest around the time that draft 8 came out. Well done
everyone.

Len
http://www.lenholgate.com
http://www.serverframework.com