IETF Logo Mail Archive

Re: [hybi] WS framing alternative

Pieter Hintjens <ph@imatix.com> Wed, 04 November 2009 10:58 UTC

Return-Path: <pieterh@gmail.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 1085A3A68BB for <hybi@core3.amsl.com>; Wed, 4 Nov 2009 02:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 uo5MvH6zNg2A for <hybi@core3.amsl.com>; Wed, 4 Nov 2009 02:58:17 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id E20E73A677D for <hybi@ietf.org>; Wed, 4 Nov 2009 02:58:16 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id l26so785447fgb.13 for <hybi@ietf.org>; Wed, 04 Nov 2009 02:58:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=vhqQXewVeE0pLXbrBIQeJSbrmLBYKqG/fp3qS5+v25g=; b=cnNhUEh3bkPpo1BcqGKyK3usMtj552FlqAqHa1XIJCzYHfITzPif8qwNgto2vCivQ6 9bYwCyCwq89SNOOpzsx+dTFiKANC9dG/4/d91ztm1v4CVoQqUG6VxxmFxMyF3ZpNkA2J B64b19n9e/rTQrmoAmXPjGP3Oa2BQl1jCNWUA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Qfk03t7Q+kU0u3WKSPp+ahad8Vwptx8a86geQDzUzFm2Be+bA0mu7ff+Tx7mtflOrK OCkaotvPMDutwrPXaEqS9unEjJwm/H5B6j1ncUK7JE+ZI09Agx3tGYQpW7NNnouRVMU5 Oc0CBQ68hAzPY0puAlAfVZ2+qTJqbIqyY7dUI=
MIME-Version: 1.0
Sender: pieterh@gmail.com
Received: by 10.87.69.28 with SMTP id w28mr3863152fgk.46.1257332314115; Wed, 04 Nov 2009 02:58:34 -0800 (PST)
In-Reply-To: <4AF0B85B.7050306@webtide.com>
References: <mailman.3820.1256908248.4669.hybi@ietf.org> <91a5e3ea0910301458q465e5778kb46bcaedc65595a6@mail.gmail.com> <4AEB7AD1.7050509@webtide.com> <Pine.LNX.4.62.0910310401280.25616@hixie.dreamhostps.com> <4AEE33AE.4080601@webtide.com> <ACE82410-B820-494F-906F-03A413D6CFE3@gbiv.com> <5821ea240911020802s37358163q4bf1a677fa3f928@mail.gmail.com> <4AEF5195.8090005@webtide.com> <5821ea240911030302w23fc34b5vc76b5dbb1028b7df@mail.gmail.com> <4AF0B85B.7050306@webtide.com>
From: Pieter Hintjens <ph@imatix.com>
Date: Wed, 04 Nov 2009 11:58:14 +0100
X-Google-Sender-Auth: 3307a781ebe84b7b
Message-ID: <5821ea240911040258r64e7b126qc7fa8f1d8a5301f@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "Roy T. Fielding" <fielding@gbiv.com>, hybi@ietf.org
Subject: Re: [hybi] WS framing alternative
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 Nov 2009 10:58:18 -0000

On Wed, Nov 4, 2009 at 12:10 AM, Greg Wilkins <gregw@webtide.com> wrote:

> BWTP is currently a thought experiment with lots of possible outcomes...

Let's assume the desirable outcome is (c), a real protocol usefully
solving real problems.

What I've missed for both BWTP and for WebSocket are clear statements
of those problems.  Undocumented assumptions.  Greg, let's collect
this for BWTP to start with: a solid list of the problems we are
aiming to solve.  Then, we can examine alternative solutions, and that
gives us the argumentation to justify BWTP, and for implementors to
understand the cost/benefit tradeoffs that went into every decision.

If it's any help this is how I designed AMQP,
http://www.openamq.org/doc:amqp-background.  That document never went
into the final spec but it was essential to position the protocol
properly, and to defend design decisions afterwards.

(Sadly with AMQP we lacked any kind of diverse community and so I made
some _terrible_ design decisions, such as encoding low-volume commands
in binary, but at least they were coherently argued terrible design
decisions.)

Cheers,
Pieter

v2.27.8 | Report a Bug | By Email | System Status