Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for max frame size

"Len Holgate" <len.holgate@gmail.com> Wed, 13 July 2011 18:36 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 B76C722801E; Wed, 13 Jul 2011 11:36:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSZVWkfWLknk; Wed, 13 Jul 2011 11:36:11 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD7FA228017; Wed, 13 Jul 2011 11:36:07 -0700 (PDT)
Received: by wyj26 with SMTP id 26so358241wyj.31 for <multiple recipients>; Wed, 13 Jul 2011 11:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=fBY+uDDFM/RE1yohLQP6nCAuEbVdUmKrFYJvN7gndrg=; b=inzVzIQ9Jn4OqY8ig0Qr8ty1rjrqmN8O+oD4sva5qrt7iJljL+qaLeKkjlMOPMEdV9 sIS3KObx+RZOBGq46/NwA2a6ugCMVRmeDbOFTc0PD7CYk9RC3659Aaetli4FpGFS9CdF ScObPFOeUxXR7QQUe7ul2If6QPMxr/D9fNgJo=
Received: by 10.216.150.150 with SMTP id z22mr5470551wej.32.1310582165518; Wed, 13 Jul 2011 11:36:05 -0700 (PDT)
Received: from Venus (cpc7-glfd6-2-0-cust20.6-2.cable.virginmedia.com [86.27.227.21]) by mx.google.com with ESMTPS id n17sm6885982wed.16.2011.07.13.11.36.03 (version=SSLv3 cipher=OTHER); Wed, 13 Jul 2011 11:36:04 -0700 (PDT)
From: Len Holgate <len.holgate@gmail.com>
To: 'Francis Brosnan Blazquez' <francis@aspl.es>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <4E1BD054.7010103@gmail.com> <1310480036.26452.329.camel@vulcan.aspl.local> <1bc701cc4135$efbf8540$0a00a8c0@Venus> <1310567252.26452.1396.camel@vulcan.aspl.local>
Date: Wed, 13 Jul 2011 19:35:53 -0000
Message-ID: <1cc601cc4194$153fcdd0$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: <1310567252.26452.1396.camel@vulcan.aspl.local>
Thread-Index: AcxBaQZNU9OGEcHESiCXt+MvxSkd1AAKqeig
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
Cc: 'Hybi' <hybi@ietf.org>, ietf@ietf.org, draft-ietf-hybi-thewebsocketprotocol@tools.ietf.org
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for max frame size
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: Wed, 13 Jul 2011 18:36:15 -0000

Francis,

> Ok, It shouldn't be a negotiation but an indication to accommodate
> communication to each party.

Fair point.

> Ok, it is important to note the peer is limiting max frame 
> size not the
> message size which may be still infinite in practical terms (63
> bits)....and we have fragmentation support to deal with this.

I understand. I was just pointing out that in your example, if the client
instead decided to limit the size of messages that it sent then then nothing
could cause any frames to be larger than that limit when they arrived at the
server.

> 1) Protocol problems should be solved on its layer, otherwise it will
>    cause next layer (application level in this case) to need to solve
>    them. It looks reasonable not forcing people to do so.

Agree.

> 2) In general, it has lot of benefits to fragment bigger messages into
>    smaller pieces to avoid sick interactions. 

Agree.

> 3) No matter API style provided by a websocket stack (frame indication
> or stream oriented), having framing running in the background 
> where the
> sending peer and intermediaries can coalesce frames without any
> indication of the upper level will cause problems that can't be solved
> in practical terms by a receiving side. 

Agree.

Len
www.lenholgate.com