Re: [hybi] updated Charter proposal

Peter Saint-Andre <stpeter@stpeter.im> Wed, 21 October 2009 15:04 UTC

Return-Path: <stpeter@stpeter.im>
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 1BCCD3A689A for <hybi@core3.amsl.com>; Wed, 21 Oct 2009 08:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.963
X-Spam-Level:
X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
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 gmXUOKz-rNuB for <hybi@core3.amsl.com>; Wed, 21 Oct 2009 08:04:17 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 241783A6980 for <hybi@ietf.org>; Wed, 21 Oct 2009 08:04:17 -0700 (PDT)
Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BA7CC40D0B; Wed, 21 Oct 2009 09:04:25 -0600 (MDT)
Message-ID: <4ADF20C7.9030601@stpeter.im>
Date: Wed, 21 Oct 2009 08:55:03 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
References: <4ADEC7A0.7040307@ericsson.com>
In-Reply-To: <4ADEC7A0.7040307@ericsson.com>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] updated Charter proposal
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, 21 Oct 2009 15:04:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Sal, thanks for this. Comments inline.

On 10/21/09 2:34 AM, Salvatore Loreto wrote:

> Proposed Charter for HyBi WG (rev.2)
> Last Updated: 2009-10-21
> -----------------------------------------------
> 
> Chairs:
> * TBD
> * TBD
> 
> Applications Area Director(s):
> * Lisa Dusseault <lisa.dusseault@gmail.com>
> * Alexey Melnikov <alexey.melnikov@isode.com>
> 
> Applications Area Advisor:
> * Lisa Dusseault <lisa.dusseault@gmail.com>
> 
> Mailing Lists:
> General Discussion: hybi@ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/hybi
> Archive: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html
> 
> Description of Working Group:
> HTTP has in the past been used as a request/response protocol most often,
> leading to clients polling for new data or users hitting the refresh button
> in their browsers.  Newer web applications are finding ways to push data
> from the server to the client as soon as it is available, through a variety
> of mechanisms.  The Hypertext-Bidirectional (HyBi) working group will seek
> standardization of approaches that HTTP clients, servers, and intermediate
> boxes can use to communicate with one another in both directions.

I'd prefer "entities" to "boxes".

Somewhere in the text we need to make it clear what kind of intermediate
entities we're talking about -- does that include entities which are in
some sense HTTP-aware or HTTP-optimized (proxies, load balancers,
caches, etc.) or also entities that are in some sense more generalized
(firewalls, network address translators, etc.).

> Since any modification of the web infrastructure may take a good amount of
> time to be deployed, outputs of the working group will include both short
> and long term solutions.  The existing web being much more complicated than
> it seems, the working group will prioritize the characterization of the
> design space, including the web clients, intermediaries, firewalls, NATs,
> web servers, etc. into which both solutions will need to be deployed.
> 
> For both short and long term work items, a general approach is preferred,
> with abstract semantics that can apply to a large number of applications.
> 
> The short term approach will be deployable on today's Internet, across
> whichever current or historical web browsers the working group decides
> upon.
> Although wide browser support is a goal, lack of support on any single
> browser version will not be a sufficient cause to block consensus.  The
> short term approach may also define hints to allow newer intermediaries to
> optimize traffic.

There's no mention of servers here.

> In the long term, new features will be required of clients, servers, or
> intermediaries allowing a more scalable and robust end-to-end experience.
> 
> Although multiple protocols exist as starting points for both the short and
> long term, backward compatibility with these protocols is not a
> requirement.
> In particular, the working group will liaison with the WebApps working
> group
> of the W3C around the Websockets protocol; if agreed by both parties, the
> HyBi working group may take over the development of the Websockets
> protocol.

I think "take on" is a bit less aggressive than "take over". :)

> Wide browser support is a goal for long term solution, however the solution
> should also be suitable for clients other than Web Browser. The Working
> Group
> will work to standardize a generic solution that can work in all the
> environments
> and elements of the web infrastructure (e.g. web browser, generic HTTP
> client,
> web server, intermediaries, etc.) and it is not specific for just one.
> 
> The Working Group should consider:
> * Implementer experience
> * Impact on existing implementations and deployments
> * Ability to achieve broad implementation
> * Ability to address broader use cases than may be contemplated by the
> original authors
> 
> The Working Group will produce one or more documents suitable for
> consideration as Proposed Standard that will:
> * Define requirements for short- and long-term solutions, including
> characterization of the design space
> * Define a short-term solution for the bi-directional web, deployable on
> today's Internet
> * Define a long-term solution for the bi-directional web, which will likely
> require modifications to the web infrastructure
> 
> 
> Goals and Milestones:
> ---------------------
> Mar-2010:  WGLC on the Design Space characterization (Informational)
> Mar-2010:  WGLC on Requirements document on Short term solution
> Mar-2010:  WGLC on Requirements document on Long term solution

Doing all of the last calls at the same time might not be a good idea.
I'd suggest spacing them out over two or three months.

> May-2010:  Requirements to IESG
> Mar-2011:  WGLC on Short term solution improvements
> May-2011:  WGLC on Long term solution protocol

Ambitious but not unreasonable, I think.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrfIMcACgkQNL8k5A2w/vy0MwCfSYklY1vpsNRg32PlizkF/+rw
IskAoJ6GpGZUe06MUpUaCgDNq8BC7nqa
=Vr14
-----END PGP SIGNATURE-----