Re: [hybi] Framing take IV

Ian Hickson <ian@hixie.ch> Wed, 04 August 2010 05:00 UTC

Return-Path: <ian@hixie.ch>
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 A3D523A6BCF for <hybi@core3.amsl.com>; Tue, 3 Aug 2010 22:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 frlUMSxNjMdp for <hybi@core3.amsl.com>; Tue, 3 Aug 2010 22:00:11 -0700 (PDT)
Received: from homiemail-a58.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 454643A67FE for <hybi@ietf.org>; Tue, 3 Aug 2010 22:00:11 -0700 (PDT)
Received: from homiemail-a58.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a58.g.dreamhost.com (Postfix) with ESMTP id 3770C7D806A; Tue, 3 Aug 2010 22:00:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=XDaJ85k+ZWtjz4SlAxEiDfFDcGO58 G+btQIhbB+Myde4GN/71TV2EDnE6+1HrFQn460D81n3PB6D4AF7ZT+BY0LiBR6MX 1LuzJqd0gLYNyH62GwZq12DTOuFBxDhcntwUGnwJbJx2JrORxYnhH4Yi/2CZB+YU hm6OparS0e/7JU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=N0cuqzAlpGocKI7i+ZgvoIqGuKw=; b=OUL 2Vuv4g5BbumELOyVRO4xWEMZi/shLgbdoC205LNP322CSuvPnmT074J5i9KK+HkC 2k56hVnOXMbHHg5O1NEbt/NNjH0L6eUmypw+j2hfMpXj+xy+jtxte7yLOTwBJ8VJ n3PzAwcX30BE8kNLVWOwkAQ3vXbce/Zgtz3nKHHg=
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a58.g.dreamhost.com (Postfix) with ESMTPSA id 1C3D47D8063; Tue, 3 Aug 2010 22:00:40 -0700 (PDT)
Date: Wed, 04 Aug 2010 05:00:39 +0000
From: Ian Hickson <ian@hixie.ch>
To: Greg Wilkins <gregw@webtide.com>
In-Reply-To: <AANLkTi=i5haWmJ49ZUcQsV0Wi47v6gkxoHm_Ctb89KQ-@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1008040439330.5947@ps20323.dreamhostps.com>
References: <AANLkTinyrDoG5d_Ur6HVRy=SgMPjLzJtpJ++Ye=1DQdj@mail.gmail.com> <Pine.LNX.4.64.1008040050040.5947@ps20323.dreamhostps.com> <AANLkTi=3CJDKu37LV+6CG=d7VP5fOe-JNV9Cd=99BjjA@mail.gmail.com> <2AD09E86-CFFE-4378-A437-7EAE2E3026FD@apple.com> <AANLkTi=i5haWmJ49ZUcQsV0Wi47v6gkxoHm_Ctb89KQ-@mail.gmail.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: hybi@ietf.org
Subject: Re: [hybi] Framing take IV
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: Wed, 04 Aug 2010 05:00:12 -0000

On Wed, 4 Aug 2010, Greg Wilkins wrote:
> 
> happy to explain again in a little bit more detail:
> 
>    - variable length length fields is more complex than a fixed length
>    length field.

I thought we weren't worried about amateur programmers?

In any case, I don't really agree that this is true. In perl, for example, 
outputting the variable-width length in the spec today is a trivial 
function call (pack('w', $length)), whereas outputting a fixed 
length field has varying levels of complexity based on whether the length 
is 32 bits, 64 bits, or 128 bits. This naturally varies based on the 
programming language, but even in the most barebone language doing bit 
manipulation is easy in practice, and not particularly prone to subtle 
hard-to-test bugs or edge cases.


>    - sending large content in a single frame is difficult if the content is
>    being generated dynamically or it's length is otherwise not known.

A variable-width length does not preclude having continuation frames if 
necessary, either at the application layer today or at the WebSockets 
layer in the future.


>    - a small fixed sized length allows simple implementations to have fixed
>    sized buffers (eg 64k)

Nothing requires a payload with a variable-width length to be read in one 
buffer, any more than a split-payload requires one buffer.


>    - fragmentation prepares the ground for future extensions for
>    multiplexing and flow control.

There's nothing in the current protocol that prevents fragmentation from 
being implemented. This has nothing to do with the length field.


>    - fragmentation on its own is not that complex

It's not clear that it's less complex than variable-width lengths. That's 
not to say that we shouldn't support it, but why require it?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'