Re: [hybi] Framing take IV

Greg Wilkins <gregw@webtide.com> Wed, 04 August 2010 03:06 UTC

Return-Path: <gregw@webtide.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 0F8BB3A680E for <hybi@core3.amsl.com>; Tue, 3 Aug 2010 20:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level:
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 6PvbS+Q-TJng for <hybi@core3.amsl.com>; Tue, 3 Aug 2010 20:06:25 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A42353A67B8 for <hybi@ietf.org>; Tue, 3 Aug 2010 20:06:24 -0700 (PDT)
Received: by fxm16 with SMTP id 16so1474822fxm.31 for <hybi@ietf.org>; Tue, 03 Aug 2010 20:06:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.126.14 with SMTP id a14mr1454362fas.44.1280891213152; Tue, 03 Aug 2010 20:06:53 -0700 (PDT)
Received: by 10.223.57.12 with HTTP; Tue, 3 Aug 2010 20:06:53 -0700 (PDT)
In-Reply-To: <F969386E-330A-4754-8644-1FB990F160A9@apple.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> <F969386E-330A-4754-8644-1FB990F160A9@apple.com>
Date: Wed, 04 Aug 2010 13:06:53 +1000
Message-ID: <AANLkTimk3MoUX5KZJZgMq=CPqW0eEY-0MSfpkWbP6B-0@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: multipart/alternative; boundary="001636c5abd2c18386048cf6b913"
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 03:06:26 -0000

On 4 August 2010 12:41, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Aug 3, 2010, at 6:29 PM, Greg Wilkins wrote:
>
> But if you have a counter proposal that you think might satisfy the
> hummers, please make it.  The current protocol certainly does not.
>
>
> Without knowing the rationale of any given hummer, I cannot predict what
> they would find satisfactory. I hope I have explained enough of my reasoning
> that others can guess whether a proposal would seem good me. Mandatory
> chunking for large messages does not sound good.
>

Maciej,

These entire framing threads a have been about trying to reach a consensus
on the concerns of the hummers  while coming up with a proposal that will
seem good to you.  I for one have been really trying to keep the complexity
to the minimum and have constantly referred back to the work needed for a
minimal client and server.    I accept that you are not convinced about
fixed lengths and fragmentation, but then you've not managed to convinced
others of the contrary and are not coming up with counter proposals that
might let us move forward.

I'm not saying that your arguments for arbitrary length frames are without
merit (and the first of my frame proposals did use the variable length
frames). But if I were the chairs, I would be calling the consensus on the
side of fixed length and fragmentation.  I guess we can do nothing other
than put our proposals and wait for a consensus call from the chairs.


>
>    - fragmentation prepares the ground for future extensions for
>    multiplexing and flow control.
>
> I'm not assuming we will need such extensions until we have data to back it
> up.
>
>
There has already been many sources of evidence that multiplexing is a
necessary extension for many environments.  You simply don't agree with that
evidence.

However, consider the four possibilities:

0) you are right about the need for multiplexing and the framing mechanism
is not capable of well supporting it
1) you are right about the need for multiplexing and the framing mechanism
is capable of well supporting it
2) you are wrong about the need for multiplexing and the framing mechanism
is not capable of well supporting it
3) you are wrong about the need for multiplexing and the framing mechanism
is capable of well supporting it

outcomes 0,1 & 3 are good outcomes.  2 is a problematic.

cheers