Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00

Micheil Smith <micheil@brandedcode.com> Fri, 09 July 2010 08:13 UTC

Return-Path: <micheil@brandedcode.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAC83A6957 for <hybi@core3.amsl.com>; Fri, 9 Jul 2010 01:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6Lk+RecGgkb for <hybi@core3.amsl.com>; Fri, 9 Jul 2010 01:13:23 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 280AF3A687C for <hybi@ietf.org>; Fri, 9 Jul 2010 01:13:22 -0700 (PDT)
Received: by pvd12 with SMTP id 12so880340pvd.31 for <hybi@ietf.org>; Fri, 09 Jul 2010 01:13:22 -0700 (PDT)
Received: by 10.114.195.15 with SMTP id s15mr10957748waf.53.1278663202183; Fri, 09 Jul 2010 01:13:22 -0700 (PDT)
Received: from [192.168.46.181] (124-170-233-189.dyn.iinet.net.au [124.170.233.189]) by mx.google.com with ESMTPS id n32sm9934719wag.11.2010.07.09.01.13.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 01:13:20 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Micheil Smith <micheil@brandedcode.com>
In-Reply-To: <op.vfj9vfna64w2qv@annevk-t60>
Date: Fri, 09 Jul 2010 18:13:18 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7A4955B-393C-498F-A0F9-4519CF3685DC@brandedcode.com>
References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <op.vfj9vfna64w2qv@annevk-t60>
To: hybi@ietf.org
X-Mailer: Apple Mail (2.1081)
Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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 Jul 2010 08:13:24 -0000

I think there's only one change, in what I've read of this thread (since the message
from Gabriel, 9th July 2010) that I could argue against as a protocol implementor
and active maintainer of a near spec-compliant server.

The only thing that does stand out is the message size constriants, which would
not be a good idea. If a client sends a message that is too large, then it is up to
the server-side developer to decide if they want to disconnect the socket for that
reason.

The second point I find interesting is the sub-protocol negotiation point, this is
something that I think would possibly be a good idea, but may add unneeded
complexity.

Also, I am that micheil person from #whatwg on irc.

Yours,
Micheil Smith
--
BrandedCode.com


On 09/07/2010, at 3:36 PM, Anne van Kesteren wrote:

> On Thu, 08 Jul 2010 20:20:15 +0200, gabriel montenegro <g_e_montenegro@yahoo.com> wrote:
>>   identified both in the HyBi wg input document
>>   [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list
>>   dicussion.
>>   REQ. 1:  The WebSocket Protocol MUST run directly on top of a
>>      transport protocol (e.g.  TCP, UDP or SCTP, DCCP).
>> ---
>> No need to say anything, as the point is that whatever HTTP was
>> running over should continue to be used after the upgrade. Typically
>> this is TCP, yes. So how about rewording thus:
>>   REQ. 1:  The WebSocket Protocol MUST run directly on top of
>>      the transport over which the initial HTTP handshake was running
>>      (typically TCP).
> 
> I think the requirement should be removed then. The requirements shouldn't constrain us to a HTTP handshake.
> 
> 
>> ---
>>   REQ. 2:  The WebSocket Protocol MUST be able to handle (send and
>>      receive) messages on top of a TCP data stream connection.
>> ---
>> Suggest rewording:
>>   REQ. 2:  The WebSocket Protocol MUST be able to handle (send and
>>      receive) messages up to a maximum size (TBD) on top of the transport
>>      over which the initial HTTP handshake was running (typically TCP).
> 
> Why should we constrain size in the requirements?
> 
> 
>>   REQ. 11:  The WebSocket Client MUST be able to request the server,
>>      during the handshake, to use a specific WebSocket sub-protocol.
>> ---
>> Suggest rewording as follows:
>>   REQ. 11:  During the handshake ,the WebSocket Client MUST be able
>> to send one or more WebSocket sub-protocol proposals to the server
>> so that the server can select one.,This results in the use of a specific
>> WebSocket sub-protocol.
> 
> I don't think this is needed. It's also something that can easily be added later if application authors find a need for it.
> 
> 
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi