Re: [hybi] updated Charter proposal

[Salvatore Loreto <[e-mail]>]

Hi Peter,

thanks for the comments... see my answers in line

/Sal

Peter Saint-Andre wrote:
> -----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 <[e-mail]>
>> * Alexey Melnikov <[e-mail]>
>>
>> Applications Area Advisor:
>> * Lisa Dusseault <[e-mail]>
>>
>> Mailing Lists:
>> General Discussion: [e-mail]
>> 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".
>   
[Sal] right, "entities" sounds much better
> 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.).
>   
[Sal] in my opinion when we talk of intermediaries we should narrow the 
scope to HTTP-aware intermediaries,  and the goal
is how to optimize them for bidirectional communication.
Then of course the HTTP proxies have to interact with Firewalls and NAT, 
but it is something that they already do nowadays,
maybe we will have to improve this interaction but I am not sure at moment.
>   
>> 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.
>   
[Sal] good catch!

    The short term approach will be deployable on today's Internet, across *HTTP proxies, servers and*
    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 *HTTP-updated* intermediaries *and servers* to
    optimize traffic.
      

>   
>> 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". :)
>   
[Sal] right lets talk of "take on"
>   
>> 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.
>   
[Sal] good suggestion. I'll reschedule and space them over two/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.
>   
[Sal] the important is to have a long term solution ready and usable for 
W3C needs asap!
We have to clarify the W3C needs and deadlines and see if we can relax a 
bit our ambitious, even if I'd prefer to keep the
second half of 2011 as final deadline.
> 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-----
>
>