Re: [hybi] how do we move forward on agreeing on framing?

Francis Brosnan Blazquez <francis@aspl.es> Fri, 20 August 2010 18:34 UTC

Return-Path: <francis@aspl.es>
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 4C9B93A6B0A for <hybi@core3.amsl.com>; Fri, 20 Aug 2010 11:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.028
X-Spam-Level: ***
X-Spam-Status: No, score=3.028 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311]
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 5ffWt0R3txmW for <hybi@core3.amsl.com>; Fri, 20 Aug 2010 11:34:26 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by core3.amsl.com (Postfix) with ESMTP id B08C63A67FE for <hybi@ietf.org>; Fri, 20 Aug 2010 11:34:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 2B8781170002; Fri, 20 Aug 2010 20:34:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYXr1ku-5OCv; Fri, 20 Aug 2010 20:34:45 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 9E0551170001; Fri, 20 Aug 2010 20:34:45 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Patrick McManus <mcmanus@ducksong.com>
In-Reply-To: <1282314477.2266.10.camel@tng>
References: <AANLkTineuhvGsC_vca6AiAX8OmHdkE-7s7rA1DQtjtMm@mail.gmail.com> <1282231803.22142.649.camel@vulcan.aspl.local> <AANLkTim44=x0BRpF3BYMqS9GNzHA+icG818JgfRRaFPT@mail.gmail.com> <1282238100.22142.732.camel@vulcan.aspl.local> <AANLkTinst1+-iTjJXfBypoOjwc+QNdVt85QopdM9w4nZ@mail.gmail.com> <1282245566.10518.11.camel@tot.local> <1282314477.2266.10.camel@tng>
Content-Type: text/plain
Organization: ASPL
Date: Fri, 20 Aug 2010 20:34:47 +0200
Message-Id: <1282329287.8341.152.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] how do we move forward on agreeing on framing?
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, 20 Aug 2010 18:34:36 -0000

> I don't agree with such a broad brushed statement like that at all.
> Layers are a convenient way to think about things, but truly layered
> implementations are almost always inferior.
> 
> See varghese's _network algorithmics_ for an amazing treatment of the
> topic.
> (http://www.amazon.com/Network-Algorithmics-Interdisciplinary-Designing-Networking/dp/0120884771/ref=sr_1_1?ie=UTF8&s=books&qid=1282314428&sr=8-1 )
> 
> Protocol designers might use layers as a useful way to articulate the
> protocol, but it is incumbent on us to consider all the various
> requirements of different implementation scenarios. That often means
> layering violations in practice. And that's ok.

Obviously we can't take any rule as inviolable, and obviously perfect
layer separation is not possible nor desirable...however, what we have
here is a flagrant attempt to design a complex protocol that was
expected to only provide transport.

It is clear in our particular case, websocket, that it will provide far
more better benefits if the protocol, as long as possible, keeps its
features at the transport level, letting other specialized application
protocols on top of it to provide what the user is looking for.

Without considering the websocket final design, inevitably people will
layer its favorite protocol on top of it. Assuming that, WG should focus
on providing features that won't be provided by upper level apps, AND,
as long as possible do to include features that are already available on
them.
-- 
Francis Brosnan Blazquez <francis@aspl.es>
ASPL