Subject: [hybi] Proposed charter for HyBi BoF in Hiroshima

From: Joe Hildebrand <[email-masked]>
Date: Tue, 22 Sep 2009 00:15:46 -0600

Please suggest changes, this is just a first draft that tries to capture
several conversations that we've had, including the bar BoF in Stockholm.

-- 
Joe Hildebrand

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
boxes 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, the amount of semantic encoded at the HyBi
layer will be minimized, allowing multiple higher-level protocols to take
advantage of the basic eventing mechanism.  These higher-level protocols are
out of scope for the working group, although liaison with other working
groups will be encouraged.

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.

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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 14:36:51 -0600

> several conversations that we've had, including the bar BoF in Stockholm.

Thanks, Joe.

I think it would be helpful in the first paragraph to mention "long
polling" as a specific instance of the "variety of mechanisms" that are
used to push data from server to client, since that term is familiar to
people.

We probably need to get input from the IETF liaison to the W3C regarding
the websockets / HTML5 discussion. Thankfully, that liaison is on this
list (Mark Nottingham).

Under deliverables, we might talk about "solutions" in the plural,
because at least in the short-term case we're probably looking at a
grab-bag of small things (an HTTP header here, a cookie format there).

Peter

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Sep 2009 22:57:20 +0200

Peter Saint-Andre wrote:
> ...
> ...

As far as I can tell, the HTML WG has decided that web sockets are out 
of scope for that Working Group:

<http://lists.w3.org/Archives/Public/public-html/2009Sep/0438.html>

BR, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 14:58:56 -0600

> <http://lists.w3.org/Archives/Public/public-html/2009Sep/0438.html>

Thanks for the clarification.

/psa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Sep 2009 23:15:43 +0200

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

...but looking at the spec, and following references, the web sockets 
API *may* have been picked up by the W3C Webapps WG.

BR, Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 23 Sep 2009 00:19:56 +0300

Hi Julian,

it is not clear to me what means the fact that web socket (protocol I 
guess) is out of scope for HTML WG does.
can you clarify it?

The Web socket API are still there, the last draft is dated September 
21th ( http://dev.w3.org/html5/websockets/ )
and those API rely on the web socket protocol, isn't it?

thanks in advance
Sal

Julian Reschke wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Sep 2009 23:27:35 +0200

> and those API rely on the web socket protocol, isn't it?

Sorry - I didn't follow the Webapps WG, so I was just commenting from 
the HTML WG's point of view.

And yes, the WebApps WG seems to be the home for the API spec.

BR, Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 23 Sep 2009 00:33:18 +0300

thanks,

now it is clear that we need to get input from WebApps WG

/Sal

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 22 Sep 2009 17:34:14 -0700

> the websockets / HTML5 discussion. Thankfully, that liaison is on this

The WebSockets API is a deliverable for the W3C's Web Apps Working  
Group, not the HTML Working Group (any more).

Regards,
Maciej