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

From: Salvatore Loreto <[email-masked]>
Date: Thu, 29 Oct 2009 11:56:26 +0200

Hi there,

here a new/updated version of the charter proposal for HyBi wg.
I have tried to include in this version all the suggestions and comments 
received in the mailing list discussion.

please provide comments!

Best Regards
Salvatore Loreto

Proposed Charter for HyBi WG (rev.3)
Last Updated: 2009-10-29
-----------------------------------------------
Chairs:
* TBD
* TBD

Applications Area Director(s):
* Lisa Dusseault <[email-masked]>
* Alexey Melnikov <[email-masked]>
 
Applications Area Advisor:
* Lisa Dusseault <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
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
entities can use to communicate with one another in both directions.

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
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 W3C WebApps 
working group
around the WebSockets protocol and the requirements to support the 
WebSocket API;
if agreed by both parties, the HyBi working group may take on prime 
responsibility
on the specification of the WebSockets protocol.

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
efficiently  in all the environments and elements of the web infrastructure
(e.g. web browser, generic HTTP client, HTTP server and HTTP-aware 
intermediaries
like proxies, load balancers, caches, 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)
May-2010:  WGLC on Requirements document on Short term solution
Jul-2010:  WGLC on Requirements document on Long term solution
Nov-2010:  Requirements to IESG
Mar-2011:  WGLC on Short term solution improvements
Nov-2011:  WGLC on Long term solution protocol

---

From: Ian Hickson <[email-masked]>
Date: Fri, 30 Oct 2009 00:54:42 +0000 (UTC)

On Thu, 29 Oct 2009, Salvatore Loreto wrote:
> 
> 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.

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.

> working group around the WebSockets protocol and the requirements to 
> support the WebSocket API; if agreed by both parties, the HyBi working 
> group may take on prime responsibility on the specification of the 
> WebSockets protocol.

We should also liason with the WHATWG, since that's where most of the 
WebSockets work has happened. (The W3C Web Apps working group hasn't 
worked on the protocol at all, and they already liase with the WHATWG for 
the API.)

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 30 Oct 2009 15:09:37 +1100

>    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

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 30 Oct 2009 12:19:43 +0200

> On Thu, 29 Oct 2009, Salvatore Loreto wrote:
<snip>
> worked on the protocol at all, and they already liase with the WHATWG for 
Hi Ian,
thanks for you comments, your are definitively right!
what about the following text?

    In particular, the working group will liaison with:
    - the W3C WebApps working group around the requirements to support 
      the WebSocket API; 
    - the WHATWG around the WebSockets protocol 
    if agreed by both parties, the HyBi working group may take on prime 
    responsibility on the specification of the WebSockets protocol.

one question: how IETF can become aware if WHATWG agrees or not?

/Sal

---

From: SM <[email-masked]>
Date: Fri, 30 Oct 2009 12:11:21 -0700

Hi Sal,
At 03:19 30-10-2009, Salvatore Loreto wrote:
>    - the W3C WebApps working group around the requirements to 
> support      the WebSocket API;    - the WHATWG around the 
> WebSockets protocol    if agreed by both parties, the HyBi working 
> group may take on prime    responsibility on the specification of 
> the WebSockets protocol.

If there is any disagreement between W3C WebApps and WHATWG, it may 
turn into a complicated situation for the proposed Working Group.  Is 
the HyBi work (the I-Ds) about the protocol or the API?

>one question: how IETF can become aware if WHATWG agrees or not?

I suggest that you talk to Lisa about that.

Regards,
-sm

---

From: Ian Hickson <[email-masked]>
Date: Sat, 31 Oct 2009 03:59:23 +0000 (UTC)

On Fri, 30 Oct 2009, Greg Wilkins wrote:
> 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:
> > 
> 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.

They have different requirements, primarily due to the differing security 
models. The origin security model makes no sense for a standalone app, 
since it controls what it sends down the wire. Such a model only makes 
sense when the handshake is done by a different party than the application 
-- indeed, it only makes sense when the application is assumed to be 
hostile. Most environments assume the application is benign.

> 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.

Could you describe concretely what use case you have in mind here? I could 
imagine, e.g., a third-party native Google Mail client wanting to pretend 
to be the GMail Web app so that it can use the same API as the web app, 
but that seems likely to be relatively infrequent compared to the number 
of cases that would just be Web apps. (It would also work fine, if that 
was really desired.) However, it seems like a much better for such an app 
to just use IMAP directly, rather than trying to reverse-engineer Google's 
internal server-client protocol.

> 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.

That's exactly what WebSocket is -- it is the layer on top of TCP that 
adds just the features that are needed for browsers. It adds nothing else. 
TCP is the protocol on which this is being layered.

The protocol stack I'm proposing looks something like this:

   |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
   | Application-level protocol | user application features
   +----------------------------+
   | WebSocket protocol         | browser security model, event wrapper
   +----------------------------+
   | TCP                        | reliability, connection wrapper
   +----------------------------+
   | IP                         | packet abstraction, routing
   +----------------------------+
   | Ethernet                   | link-level routing
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

What is the protocol stack you are imagining? What are the features that 
TCP lacks that you think need to be added between the "IP" and 
"Application-level protocol" layers of the stack above? Where do you think 
features like the browser-level origin model should fit?

On Fri, 30 Oct 2009, Salvatore Loreto wrote:
> > worked on the protocol at all, and they already liase with the WHATWG 
> > for the API.)
>
>    - the W3C WebApps working group around the requirements to support      the
> WebSocket API;    - the WHATWG around the WebSockets protocol    if agreed by
> both parties, the HyBi working group may take on prime    responsibility on
> the specification of the WebSockets protocol.
>

The WHATWG is happy to work with anyone. I don't understand what you mean 
by "liason with" juxtaposed by "take on prime responsibility", though. In 
what sense is it a liason if the other group no longer has responsibility? 
Surely a joint effort implies joint responsibility.

It should be noted that the WHATWG's work is based on technical merit and 
not on consensus. If even just one person raises a valid technical issue 
in the WHATWG, they cannot be overridden by the rest of the group having 
complete agreement that they should just ignore the technical issue. There 
is also a firm philosophy that the specs match interoperable deployed 
implementations, and that the specs not leave things undefined.

Does the IETF/Hybi agree?

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 31 Oct 2009 16:22:31 +1100

> The protocol stack I'm proposing looks something like this:

Currently you are insisting that there
are no layers between websocket and TCP or
between the application and websocket.
That is hardly and endorsement of a layered
approach.

> What is the protocol stack you are imagining? 

What I'd like to see is:

   |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
   | Application-level protocol | user application features
   +----------------------------+
   | BWT browser binding        | browser security model
   +----------------------------+
   | Optional transport features| Multiplexing, compression, etc.
   +----------------------------+
   | Bidirectional Web Transport| Two way communications through firewalls etc.
   +----------------------------+
   | TCP                        | reliability, connection wrapper
   +----------------------------+
   | IP                         | packet abstraction, routing
   +----------------------------+
   | Ethernet                   | link-level routing
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

What I'm currently trying to compromise on is:

   |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
   | Application-level protocol | user application features
   +----------------------------+
   | Optional transport features| Multiplexing, compression, etc.
   +----------------------------+
   | Websocket protocol         | Two way comms, browser security model
   +----------------------------+
   | TCP                        | reliability, connection wrapper
   +----------------------------+
   | IP                         | packet abstraction, routing
   +----------------------------+
   | Ethernet                   | link-level routing
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

> What are the features that
> "Application-level protocol" layers of the stack above?

I want a transport that will provide bidirectional communications
through the web - where my definition of the web is the internet as
deployed with firewalls, NAT routers, aggregation, load balancers,
SSL offload, etc.

HTTP is a reasonable web transport, but it is not bidirectional

> Where do you think features like the browser-level origin model should fit?

Above the transport layer.
Below the application layer.

Where do you think features like multiplexing should fit?
I think you are advocating in the application layer - which is
just wrong!

> The origin security model makes no sense for a standalone app,

And because the origin model implementation uses a standard
meta data channel (HTTP headers), applications that don't care about
it can simply ignore it and still work!!!!   Websocket is using
this technique in it's own handshake, but denying the same
technique to anything built on top of websocket.

Ian Hickson wrote:
> I must admit to being more interested in technical soundness than 
> consensus. 

Do you realize how arrogant that reads and how
non-constructive that is towards creating a civil
conversation?

We've not question your technical credentials to
participate in this forum, so please do not imply that
those that disagree with you cannot propose technically
sound solutions.

> I thought that's what I was doing: responding to proposals with counter 
> proposals, 

I'm still waiting for a single counter proposal other than
to say the application layer can do it all.

> Reducing kilobytes of data to 2 bytes is more than "a little more byte 
> efficient", 

HTTP headers used for most comet interactions are not kilobytes.

Even if there were, there are proposals that can be made to
browser/server developers to greatly reduce the overheads of
headers.

Data rate is not a big problem for me - but I acknowledge
others might want to do better.

> and reducing latency from 150ms (TCP round trip to set up the
> connection plus a packet for the message) to 50ms (just the packet for the 
> message) is far more than marginal.

We just benchmarked a comet installation using HTTP long
polling that handled 8000 clients with an average 60ms
latency.

Latency is not a big problem for me - but I acknowledge
others might want to do better (specially for max latency).

> It halves the number of connections relative to current solutions. 
> I would  hardly characterise one connection per user as bloat --

It does not decrease the connections.  At the very least it
will add one connection because it can't be used for normal
HTTP - so those connections will still be used for normal
ajax stuff (or just held idle)

It is not one connection per user.    It is one connection
per end point that the application creates per frame, per tab
per window per user.

The number of connections IS a problem for me and others -
but I acknowledge that others don't give a damn.

Ideally if we had shared multiplexed with fragmentation that
were capable of carrying HTTP as well as bidirectional datagrams,
then we would be able to truly have 1 connection per client.

>> It's going to break all the load balancers I work with and the SSL 
>> offloaders and most other network infrastructure.
> 
> Could you elaborate on what requirements your load balancers and SSL 
> offloaders have which, if addressed, would lead to WebSocket working with 
> them to your satisfaction?

It's not "my satisfaction".    I'm just telling you that there is a
big industry in developing intermediaries that do all sorts of funky
stuff with HTTP - mostly based on the ability to pass meta data.

I don't know what they all do... I don't even think all the ones I
know about are good ideas.

But yet they still exist.  Like it or not, they will continue to
exit.    Trying to ignore them is just not going to be helpful.

I've already given you plenty of examples

---

From: SM <[email-masked]>
Date: Sat, 31 Oct 2009 09:35:59 -0700

>Surely a joint effort implies joint responsibility.

Editorial comment:  That should have been "the working group will 
liaise with the ...".

Joint responsibility increases the chances of failure as two working 
groups do not work the same way.

>implementations, and that the specs not leave things undefined.

The IETF process is based on consensus.  An IETF Working Group cannot 
change that.  The philosophical questions can be addressed in the 
charter if the group reaches a consensus about that.

My comments are as an individual.  The proposed WG will be part of 
the IETF.  It is not the IETF.  The entire IETF community will be 
asked to comment on the proposal submitted for publication.  The IETF 
does not constrain the solution.  It is up to the IETF participants 
to determine what problem will be solved and how it will be 
solved.  There's the BoF and this mailing to discuss about all that 
and come up with a proposed charter.  People from the W3C WebApps and 
WHATWG are not excluded.  Ask them to join this mailing list and participate.

Regards,
-sm