Subject: [hybi] new version hybi-requirements

From: Salvatore Loreto <[email-masked]>
Date: Mon, 08 Mar 2010 21:48:48 +0200

Hi there,

I have submitted a new version of the "HyBi Requirements and Features"
http://www.ietf.org/id/draft-loreto-hybi-requirements-01.txt

I have changed and rephrased requirements following the consensus in the 
mailing list.

I have not inserted yet any requirements on extension and subprotocol, 
as I haven't seen
a clear consensus on it.

I look forward to see your comments and feedbacks.
The draft will be also discussed during the meeting in Anaheim.

As chair, I will maintain editorship of the draft, with a goal of naming 
editors at (or soon after) IETF 77
  - If you are interested in editing either of those drafts, please 
email the chairs off-list.

Cheers
Sal

-- 

Salvatore Loreto
www.sloreto.com

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 08 Mar 2010 12:54:15 -0800

Salvatore Loreto wrote:
> I have changed and rephrased requirements following the consensus in 
> the mailing list.
>
>    REQ. 11:  The WebSocket Client MUST be able to request the server,
>       during the handshake, to use a specific WebSocket sub-protocol.
>   

Validation might be a cleaner requirement than extension (I think REQ 11 
captures the idea), because clients and servers will want to verify that 
they're speaking the same protocol (and possibly verify the version) so 
they don't send incomprehensible frames to each other.  For example, 
even a simple a tic-tac-toe client will want to ensure it's really 
talking to a tic-tac-toe server and not a chat server. (Or a server may 
upgrade/change a version and want to redirect legacy clients to a 
different URL.)

Negotiation/extension may or may not be a requirement (e.g. using HTTP 
redirects), but I think validation of the sub-protocol is a must have, 
even if the client is just checking that the server is expecting raw 
text strings vs binary.

So REQ 11 might have a corresponding server requirement, where the 
server can reject the upgrade if the client's sub-protocol is missing 
(and obviously allow the server to reject the connection if the 
sub-protocol is wrong.)

-- Scott
> As chair, I will maintain editorship of the draft, with a goal of 
> naming editors at (or soon after) IETF 77

---

From: rektide <[email-masked]>
Date: Wed, 17 Mar 2010 03:27:06 -0600

> http://www.ietf.org/id/draft-loreto-hybi-requirements-01.txt

Forgive me for apparently not understanding the purpose of this working group, but why are
hybi's requirements all tied directly to WebSocket?  Is this group bound 100% to evolving
WebSocket and its current implementation?  Are no other options tennable?

I agree with the premise that "The goal of HyBi is to provide an efficient and clean two-way
communication channel between client and server," that will provide certain abilities.  But
to say, immediately following, that these abilities MUST be provided by WebSocket gives me
the impression this discussion is only about WebSocket.

- rektide

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 17 Mar 2010 11:16:31 +0100

> WebSocket and its current implementation?  Are no other options tennable?

Rektide,

When I joined the hybi effort at the IETF, I did advocate that we look at
other options to fit the needs at hand.

However, to paraphrase my understanding of IETF process, it is all about
rough consensus and working code and it is not about designing new solutions
by committee. So the rough consensus at the BOF in Hiroshima, was that the
WG should focus on standardizing the working code that is at hand - ie websocket.

I do not think that means that other options like SPDY and BWTP are not
able to be consider at some stage by the IETF - just that they are not
the immediate focus of this working group.

Note also, that while I am a vocal critic of the websocket protocol,
I do recognize that it has the interest of the browser vendors and
developer community.   So I actually believe that the best path to
a workable solution is to take that momentum and incrementally
improve the protocol/specification.   So I now share this working
groups focus on websocket.

In my current version of a perfect world, websocket's framing
would be rationalized somewhat,  the intermediaries on the internet
would be upgraded to well support it, and then richer protocols
like SPDY and BWTP could build on websockets rather than
re-invent ways to bidirectionally traverse the web.

cheers

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 17 Mar 2010 14:47:57 +0000

> (and obviously allow the server to reject the connection if the 

When it does get rejected, it's highly desirable that the client can
try again with different parameters on the same connection.

Otherwise the only way for a client to negotiate a newer protocol and
be backward compatible with older servers will be to cache the
behaviour of a particular IP address and port - and hope it gets the
same server each time it connects.  Also, that's slow, and pushes NAT
connection limits.  (Trying again is also a bit slow but I don't
expect consensus on anything more sophisticated).

-- Jamie