Re: [hybi] Proposed Charter for HyBi WG (rev.3)

Greg Wilkins <gregw@webtide.com> Fri, 30 October 2009 04:09 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 1809A3A680D for <hybi@core3.amsl.com>; Thu, 29 Oct 2009 21:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level:
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 qFbsCtaIMpOY for <hybi@core3.amsl.com>; Thu, 29 Oct 2009 21:09:33 -0700 (PDT)
Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 1B7743A686A for <hybi@ietf.org>; Thu, 29 Oct 2009 21:09:33 -0700 (PDT)
Received: by gxk28 with SMTP id 28so2503247gxk.9 for <hybi@ietf.org>; Thu, 29 Oct 2009 21:09:47 -0700 (PDT)
Received: by 10.150.251.10 with SMTP id y10mr2005211ybh.49.1256875786921; Thu, 29 Oct 2009 21:09:46 -0700 (PDT)
Received: from ?10.10.1.9? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 13sm772391gxk.1.2009.10.29.21.09.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 21:09:45 -0700 (PDT)
Message-ID: <4AEA6701.1010808@webtide.com>
Date: Fri, 30 Oct 2009 15:09:37 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <4AE966CA.9090907@ericsson.com> <Pine.LNX.4.62.0910300047310.25608@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0910300047310.25608@hixie.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Proposed Charter for HyBi WG (rev.3)
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, 30 Oct 2009 04:09:34 -0000

Ian Hickson wrote:
> I think that's the wrong characterisation of the spaces that people want 
> to work in. I think a better way to characterise it would be that there 
> are three use cases people are interested in, with different needs:
> 
>  * Providing a standard way of doing two-way communication tunneled over 
>    HTTP, for use by applications that cannot use TCP, Jabber, BEEP, or 
>    other existing solutions in that space due to intermediaries, 
>    firewalls, NATs, etc.
>
>  * Providing something as close to TCP as possible to Web applications 
>    (i.e. JavaScript running in HTML on Web browsers), while maintaining 
>    the Web origin security model and fitting the Web development model 
>    (e.g. event-based, not stream-based).
>
>  * Providing a standard way of doing "hanging-GET" two-way communication 
>    to HTTP servers along the lines of what interactive AJAX pages do.

Ian,

I don't see why you consider the first two as entirely
different audiences.  Web applications (i.e. JavaScript running
in HTML on Web browsers) are just any other application (like Jabber,
BEEP etc) that wants two-way communication over the web.

>From the point of view of server or an intermediary, there is
very little difference between any of the different client
application types that might be out there and I don't want to
have to double my effort to consider them differently.

I agree that webapps/browsers have some specific requirements - eg
in regards to the Web origin security model - but surely those extra
requirements should be layered on top of the protocol, not baked
in as assumptions that will force an entirely new protocol
to be used for non-browser clients.

regards