Subject: [hybi] updated Charter proposal

From: Salvatore Loreto <[email-masked]>
Date: Wed, 21 Oct 2009 11:34:40 +0300

Hi there,

here a new/updated version of the charter proposal for HyBi wg.
This version includes all the suggestions and comments received in the 
the list discussion.

please provide comments!

Best Regards
Salvatore Loreto

Proposed Charter for HyBi WG (rev.2)
Last Updated: 2009-10-21
-----------------------------------------------

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

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.

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
May-2010:  Requirements to IESG
Mar-2011:  WGLC on Short term solution improvements
May-2011:  WGLC on Long term solution protocol

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 08:55:03 -0600

Hi Sal, thanks for this. Comments inline.

> Proposed Charter for HyBi WG (rev.2)

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

> short term approach may also define hints to allow newer intermediaries to

There's no mention of servers here.

> HyBi working group may take over the development of the Websockets

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

> require modifications to the web infrastructure

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-2011:  WGLC on Long term solution protocol

Ambitious but not unreasonable, I think.

Peter

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

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 22 Oct 2009 02:08:17 +0100

> (firewalls, network address translators, etc.).

Firewalls and NATs are quite important to HyBi.  Because the server
can't initiate connections, it's necessary for connections to be kept
open as long as the client wishes to receive messages.  Firewalls and
NATs need enough keepalive packets to stop them blocking a connection
in mid use.  And "ping" requests with responses from one side are
not the most efficient way to do that.

HyBi may also need a strategy to cope when a firewall or NAT
spontaneously blocks a connection in the middle of it's use too.  That
might be deferred to the application (bet lots of them will get it
wrong if so), but it should at least be addressed.

-- Jamie

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Oct 2009 12:36:54 +0200

Hi Peter,

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

/Sal

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
[Sal] right, "entities" sounds much better
> (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.
> 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.

> I think "take on" is a bit less aggressive than "take over". :)
[Sal] right lets talk of "take on"
> I'd suggest spacing them out over two or three months.
[Sal] good suggestion. I'll reschedule and space them over two/three months
> 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-----
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Oct 2009 12:53:31 +0200

> wrong if so), but it should at least be addressed.
I agree that we have to take in consideration Firewalls and NATs during 
the design of a Bidirectional protocol
(both short and long term), and this is extremely important for HyBi.
However the HyBi wg should not have any ambition to improve the 
Firewalls and NATs, but only design a protocol that
cooperate well with them and improve the existing HTTP entities to 
improve the interaction with the existing Firewalls and NATs.

cheers
/Salvatore

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 25 Oct 2009 17:34:11 +0000

> improve the interaction with the existing Firewalls and NATs.

Fwiw, I agree completely.

It may involve characterising firewalls and NATs, for example to
suggest keepalive message rates and strategies.  I wouldn't be
surprised if another part of IETF has investigated that already in a
more general context or for some other protocol.

The issue of connections being dropped, and detecting when this has
happened, and perhaps recovering, is more general than firewalls and
NATs.  E.g. mobile IP has the same problem.  I don't know if it needs
to appear anywhere in HyBi or if it can be dealt with entirely in the
application layer.  But it is worth looking at, because a web full of
applications which deal with it badly is a less desirable outcome than
a web full of applications which handle it well, and we _might_ be
able to make a big difference there.

-- Jamie

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Oct 2009 20:23:22 +0200

Hi Jamie

see my answers in line

> more general context or for some other protocol.
[Sal] IETF behave wg is working on this aspects: 
http://tools.ietf.org/wg/behave/
have a look at "NAT Behavior Discovery Using STUN" draft: 
http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-08

> able to make a big difference there.
[Sal] of course the issue of detecting a connection being dropped is a 
more general problem that can happen
in several scenario other then in firewalls/nats.
Do you have a text/statement proposal to insert in the chart about it?

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 25 Oct 2009 15:10:03 -0700

Salvatore Loreto wrote:

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

Could we detune this from support of the specific Websocket protocol?
How about:

  In particular, the working group will liaison with the WebApps working
  group of the W3C around a protocol to support the Websockets API; if agreed
  by both parties,  the HyBi working group may take on prime responsibility
  for the specification of the protocol.

regards

---

From: Ian Hickson <[email-masked]>
Date: Mon, 26 Oct 2009 00:07:05 +0000 (UTC)

On Sun, 25 Oct 2009, Greg Wilkins wrote:
> > 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 WebSocket protocol right now is a WHATWG/hybi effort, the W3C WebApps 
group isn't working on the protocol.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 26 Oct 2009 09:45:36 +0200

> group isn't working on the protocol.
[Sal] I agree with Greg,
the wg should liaison with W3C WebApps wg around the requirements to 
support the Websocket API,
but then the HyBi wg respecting the requirements of the browsers and in 
general all the W3C requirements,
should also take in consideration requirements coming from 
intermediaries, infrastructure providers and/or even servers

about detuning or not the charter from the support of the specific 
WebSocket protocol, it will depend from the consensus of people
both in the mailing list discussions (so please speak up about this 
point) and/or during the BoF in Hiroshima;
my personal opinion is that considering all the efforts people have 
spent during the last years on WebSocket protocol it is reasonable
assume WebSocket to be *the basis* of the long term approach.

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 26 Oct 2009 00:51:54 -0700

> assume WebSocket to be *the basis* of the long term approach.

I agree with that point of view. It seems sensible to use WebSocket  
Protocol as the starting point, even if we see the need to add  
features or otherwise change the protocol. There doesn't seem to be a  
strong case for starting from scratch.

  - Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 26 Oct 2009 21:35:14 +1100

Maciej Stachowiak wrote:
> Protocol as the starting point, even if we see the need to add features
> or otherwise change the protocol. There doesn't seem to be a strong case
> for starting from scratch.

I agree that an amended WebSocket protocol is a probably and desirable
outcome.

However, I don't think the charter should mandate the WebSocket protocol
as the outcome.

The protocol should be able to be selected on it's own merits - and
that includes the effort that many have put towards it already.

However, it may be that the WG discovers some issue that forces a
substantial change and that should be possible within the charter.

cheers

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Oct 2009 11:51:46 +0100

Greg Wilkins wrote:
> ...

+1

BR, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 26 Oct 2009 11:39:29 -0700

> that includes the effort that many have put towards it already.

Hi Greg,

Asking WGs to run beauty contests typically turns out to be
problematic.  I think we get better success at asking whether it's
appropriate to form a WG around a specific proposal, and that doesn't
exclude other WGs and other proposals.  It's really the WG formation
process that lets the entire IETF decide if a WG working on the
WebSocket protocol is the right thing to do.   That process does
address the merits, and it avoids the "there can be only one" fallacy.

Lisa

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 27 Oct 2009 10:52:11 +1100

> address the merits, and it avoids the "there can be only one" fallacy.

OK if that's the process, then that's the process.

However, the authors of the protocol have so far been very
resistant to change (not even using BNF or allocating a
type byte for mime-encoded content).

So will the WG have the ability to come up with it's own
draft for a websocket protocol - or will all it be able
to do is huff and puff and hope to convince the whatwg?

The problem with that approach is that the whatwg
have a different world view (js only, not so hard
to release new versions, run around intermediaries, keep it
totally simple) to many view expressed in the IETF forum
(many client types, hard to release new versions, involve
the intermediaries, make it extensible).

It maybe that the websocket protocol is perfect
for the whatwg's objectives, but insufficient for
the IETF's.   I'm not sure how we get past that
log jam if the WG is not able to author its
own protocol or variations?

regards

---

From: Ian Hickson <[email-masked]>
Date: Tue, 27 Oct 2009 00:14:30 +0000 (UTC)

On Mon, 26 Oct 2009, Greg Wilkins wrote:
> [...] I don't think the charter should mandate the WebSocket protocol as 
> the outcome.
> 
> The protocol should be able to be selected on it's own merits - and that 
> includes the effort that many have put towards it already.

I agree with Greg that it would be inappropriate for the WG to be bound to 
adopt a particular proposal or rubber-stamp a particular proposal.

What matters much more is that the group's deliverables have the buy-in of 
the relevant implementors -- if we write a technology that is intended to 
be implemented by proxy vendors, then proxy vendors need to be willing to 
implement it. If we write a technology that is intended to be implemented 
by Web browsers, then Web browsers need to be willing to implement it. 
Otherwise, we're just wasting our time writing boring science fiction.

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 26 Oct 2009 17:21:25 -0700

> to do is huff and puff and hope to convince the whatwg?

I would expect the standard for deciding the contents of an eventual  
RFC will be "rough consensus and running code".

Regards,
Maciej

---

From: Ian Hickson <[email-masked]>
Date: Tue, 27 Oct 2009 00:25:19 +0000 (UTC)

On Tue, 27 Oct 2009, Greg Wilkins wrote:
> 
> However, the authors of the [WebSocket] protocol have so far been very 
> resistant to change (not even using BNF or allocating a type byte for 
> mime-encoded content).

ABNF is used three times in the WebSocket draft.

You and I have a disagreement about whether it is appropriate for the 
protocol to have a type byte for MIME-encoded content.

However, the draft itself has changed a lot in response to feedback over 
the years. The original proposal really has no resemblence to the current 
proposal:

   http://www.whatwg.org/specs/web-apps/2005-09-01/#network
   http://www.whatwg.org/specs/web-apps/2006-01-01/#scs-network

I don't adopt every proposed change, sure, but I think I have shown myself 
to be quite willing to change the proposal based on reasoned arguments and 
clearly demonstrated needs and problems.

> So will the WG have the ability to come up with it's own draft for a 
> websocket protocol - or will all it be able to do is huff and puff and 
> hope to convince the whatwg?

Say the WG adopted BWTP as the basis for its work. Will you drop 
Multiplexing and MIME typing from the BWTP proposal? If not, does that 
mean you are resistant to change and then will the WG only be able to huff 
and puff and hope to convince you?

> The problem with that approach is that the whatwg have a different world 
> view (js only, not so hard to release new versions, run around 
> intermediaries, keep it totally simple) to many view expressed in the 
> IETF forum (many client types, hard to release new versions, involve the 
> intermediaries, make it extensible).
> 
> It maybe that the websocket protocol is perfect for the whatwg's 
> objectives, but insufficient for the IETF's.  I'm not sure how we get 
> past that log jam if the WG is not able to author its own protocol or 
> variations?

If the WG were to adopt an approach that was based on not having JS as the 
primary client type, assuming that we couldn't update the protocol 
frequently, assuming that the protocol would have to be implemented in 
intermediaries to be successful, and assuming that extensibility at the 
protocol user level (rather than layered on top of the protocol, or done 
through updates to the protocol) was desireable, then I don't think I'd be 
interested in the group's deliverables, to be honest.

What I'm looking for is something that is designed for JS clients, that 
can be updated regularly, that can be adopted today without bootstrapping 
through intermediaries, and that is kept as simple as possible (while 
allowing the protocol to be extended by future updates).

I don't mind what the working group works on, but if it's not that, then 
it's not a working group I'm interested in working with, as it wouldn't 
be addressing the needs that I'm trying to address.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Oct 2009 12:05:45 +1100

My .02 (repeating some things that have been said by others) --

A WG that has a definite charter to do a specific piece of work has a  
much greater chance of success than one that is tasked with picking a  
winner; even if the WG fails as a whole or needs to be rechartered  
later because it isn't working, it's much more productive to be  
working on one identified thing.

I think a charter for a WG along these lines needs to very carefully  
spell out what criteria that proposed changes to WS needs to meet; it  
will be very easy for it to become unproductive otherwise.

I don't think that the characterisation that Ian has been reluctant to  
take feedback is merited; I've seen him incorporate feedback from  
several communities. Of course, he's operating with a fairly strict  
set of criteria for changes to WS; YMMV.

Cheers,

On 26/10/2009, at 9:10 AM, Greg Wilkins wrote:

>> parties,
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Oct 2009 12:07:36 +1100

Ian --

There really isn't anything for proxy vendors to implement in  
WebSockets, is there? Provided that they support CONNECT, of course.

To get proxy vendors on board, there will need to be overlay protocols  
that allow them, for example, to multiplex many client connections  
into one server connection, but that's far and above what WS does.

Or do you intend to go in that direction?

Cheers,

On 27/10/2009, at 11:14 AM, Ian Hickson wrote:

>> that

---

From: Ian Hickson <[email-masked]>
Date: Tue, 27 Oct 2009 01:24:40 +0000 (UTC)

> WebSockets, is there? Provided that they support CONNECT, of course.

Right; as written, WebSocket can be used with explicit SOCKS or HTTP 
proxies (in the latter case using CONNECT), and there's no built-in 
support for dedicated WebSocket proxies though man-in-the-middle proxies 
could be written to handle unencrypted WebSocket proxies if there was a 
need to do so (though I can't see what the point would be).

> that allow them, for example, to multiplex many client connections into 
> one server connection, but that's far and above what WS does.
>

Not currently. I don't see why we would.

I would expect server-side implementations to translate incoming WebSocket 
connections into appropriate internal connections; e.g. if Example Corp 
uses RPC extensively internally in their datacenters, a front-line server 
could receive a long-lived WebSocket connection (speaking that site's 
subprotocol) and translate it into short-lived RPC on the backend. 
However, that would be layered above WebSocket just like this kind of 
thing is layered above hanging-GET systems today.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Oct 2009 12:27:56 +1100

> thing is layered above hanging-GET systems today.

Yeah. In theory it would be nice if, for example, a corporate or ISP  
proxy could "manage" a bunch of WS connections back to a third-party  
service provider, but there's a lot of risk and overhead to going down  
that path, and not a tremendous amount of benefit.

I suspect most of the intermediary cases that are going to come up for  
WS in the near future are going to be server-side (like HTTP  
accelerators/reverse proxies), and they're already under the control  
of the server, so they can coordinate.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 27 Oct 2009 20:21:17 +1100

Ian Hickson wrote:

> the years. 

My apologies - I probably over stated the case that the ws authors
are resistant to  change.

I think it is more accurate to say that you are more resistant to
requirements other than your tight focus on a minimal protocol to
enable a close socket equivalent to js running in a browser.

I think resolving the differences in requirements is the prime
task the IETF WG will have.     Once their is rough consensus
on the requirements - most of the protocol design is a matter
of style.

> and puff and hope to convince you?

I'm not proposing that BWTP is written into the charter as the
only possible option.

I don't really care what protocol is accepted, so long as it
makes my job as a comet infrastructure developer easier.
For me this means:

+ abstract applications developers away from TCP/IP
  connection management
+ minimize connection growth on the server side
+ allow for flexible and extensible usage.
+ allows intelligent intermediaries to participate
  (load balancers, concentrators, SSL offloaders etc.)

BWTP attempts to meet those with channels based multiplexing and
support for mime encoding.    But there are many ways to solve those
and my first preference was to enhance the WS proposal.   BWTP
was only developed as an alternative because WS just does not
address any of the pain points I have as a comet server developer.

> be addressing the needs that I'm trying to address.

So perhaps we have wasted a lot of time debating protocol design,
when we should have been discussing protocol requirements.

Then maybe we need two WGs and 2 protocols?

regards

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 27 Oct 2009 20:34:11 +1100

> need to do so (though I can't see what the point would be).

For HTTP, there is a huge industry involved in providing value
add intermediaries that do all sorts of things:

 + connection aggregation
 + caching
 + load balancing
 + SSL offload
 + virus scanning
 + NSFW scanning
 + auditing
 + language translation
 + authentication, accounting and auditing
 + hanging get or long poll offload
 + mashups and portal based aggregation
 + advert insertion
 + advertisement insertion
 + debugging aids

This list is just off the top of my head.  I'm sure
there are many many many more web intermediaries out there.

These products exist not because of deficiencies in HTTP, but
due to real needs that have evolved from our usage of
request/response data on the internet.  They are able to
do powerful things because of the good semantic content
of HTTP messages.

I don't think it is a stretch to imagine that when we start
exchanging bidirectional data, that similar and/or new
needs for value adding intermediaries will evolve.

Even with the low semantic content of ws messages, I can
imagine that intermediaries will develop to reverse
engineer content and manipulate /monitor/control it in
some fashion.

So I see it as prudent to have a protocol that at least
acknowledges that intermediaries might exist as parties
with at least the ability to close connections if
not participate on them.

Having a bidirectional protocol that does an
end-run around intermediaries is not going to
avoid these needs arising.

regards

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 27 Oct 2009 14:11:50 +0200

it seems to me that there are opportunity reasons (e.g. do a specific 
piece of work; the efforts people have spent during the last years on WS)
but also some consensus on focus the WG long term solution on WebSocket 
protocol

however what is not clear is *"what criteria that proposed changes to WS 
needs to meet"* (as suggested by Mark)

so far Ian has followed a fairly strict set of criteria for changes to 
WS (from Ian mail: 
http://www.ietf.org/mail-archive/web/hybi/current/msg00695.html);
mainly
- keep the protocol simple
- specifically designed for JS clients
- possibility to update it regularly without bootstrapping through 
intermediaries

(Ian, please correct me if I have misinterpreted you)

However there are people in the group that do think the criteria for 
changes should be less strict and also take in consideration 
intermediaries,
infrastructure providers and/or even servers and also clients different 
from JS clients.

So I'd like have a discussion in the mailing list about the criteria 
that proposed changes to WS need to meet

cheers
/Sal

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Oct 2009 14:57:53 +0100

> Otherwise, we're just wasting our time writing boring science fiction.

My understanding is that you want the protocol to be implemented by Web 
browsers, right? In which case the WG should make sure that those people 
actually intend to join the working group.

Having a consensus-driven process that doesn't involve those who are 
supposed to implement the protocol would be a problem.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 27 Oct 2009 16:14:13 +0100

> supposed to implement the protocol would be a problem.

It seems representatives of all the "browser companies" are subscribed to  
this list. My understanding from joining the HTTP WG was that this is all  
it takes to be a member.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Oct 2009 17:29:37 +0100

Anne van Kesteren wrote:
> On Tue, 27 Oct 2009 14:57:53 +0100, Julian Reschke 
> <[email-masked]> wrote:
>> My understanding is that you want the protocol to be implemented by 
>> Web browsers, right? In which case the WG should make sure that those 
>> people actually intend to join the working group.
>>
> It seems representatives of all the "browser companies" are subscribed 
> to this list. My understanding from joining the HTTP WG was that this is 
> all it takes to be a member.

Yes, that is true.

What I meant is that these companies should *participate* in the WG, 
rather than sending feedback off-list to the editor.

BR, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 28 Oct 2009 08:28:59 +1100

> all it takes to be a member.

What about representation from network and server side companies?

Is there anybody here from Cisco, Citrix, Barracuda, F5,
apache, websphere, weblogic, resin, light streamer ?

Anybody have contacts with such companies who can reach
out and invite them to participate?

regards