Subject: [hybi] -03

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sun, 17 Oct 2010 13:15:21 -0700

I am about to send out a -03 of the protocol. I have closed out all of the
issues in the issue tracker [1] for the text that has been merged, and mail
has already gone to the list regarding these issues so I am not going to
duplicate all of that in this message. I have been using the issue tracker
to ensure that I don't miss anything. If I missed some text or concept that
you wanted included in the draft, I apologize in advance. I'm happy to add
it in, please email SM and ask him to create an issue to track the item and
I will include it in -04. As there's still significant ongoing discussion
about replacing the handshake, I did not merge in Adam's alternate handshake
proposal [2].

[1]
http://trac.tools.ietf.org/wg/hybi/trac/report/1?asc=1&sort=ticket&USER=anonymous
[2] http://trac.tools.ietf.org/wg/hybi/trac/ticket/25

---

From: Fumitoshi Ukai (鵜飼文敏) <[email-masked]>
Date: Mon, 18 Oct 2010 16:05:57 +0900

Thanks for updating!

Could you update protocol overview section to include "Sec-WebSocket-Draft",
please?  I thought we still don't have any thing to distinguish older
version, but noticed that Sec-WebSocket-Draft is used in opening handshake.

I'm also wondering what if websocket server only knows hixie -76 and client
tries to open websocket draft 2?  websocket spec has been saying that
unrecognized fields can be safely ignored, so opening handshake will
succeed, but client thinks it's draft2, but server thinks it's hixie -76...
Shouldn't server also response back Sec-WebSocket-Draft to make sure both
agree the version?

-- 
ukai

On Mon, Oct 18, 2010 at 05:15, Ian Fette (イアンフェッティ) <[email-masked]>wrote:

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

---

From: Micheil Smith <[email-masked]>
Date: Mon, 18 Oct 2010 18:25:57 +1100

Hi,

Would it be possible for someone to create a reference implementation of the client? 
I'm probably going to write a server for this version of the protocol soon and it'd be good 
to have something to test against.

Yours,
Micheil Smith
--
BrandedCode.com

On 18/10/2010, at 7:15 AM, Ian Fette (イアンフェッティ) wrote:

> I am about to send out a -03 of the protocol. I have closed out all of the issues in the issue tracker [1] for the text that has been merged, and mail has already gone to the list regarding these issues so I am not going to duplicate all of that in this message. I have been using the issue tracker to ensure that I don't miss anything. If I missed some text or concept that you wanted included in the draft, I apologize in advance. I'm happy to add it in, please email SM and ask him to create an issue to track the item and I will include it in -04. As there's still significant ongoing discussion about replacing the handshake, I did not merge in Adam's alternate handshake proposal [2].
> 
> [1] http://trac.tools.ietf.org/wg/hybi/trac/report/1?asc=1&sort=ticket&USER=anonymous

---

From: "Kensaku KOMATSU" <[email-masked]>
Date: Mon, 18 Oct 2010 19:53:43 +0900

I also agree with Ukai's opinion. I little wondered that including draft
revision number into protocol header is suitable on not.
But current situation(hard to distinguish these incompatible protocols) is
not suitable for testing update version of protocol
among developers(like me). It will prevent to improve websocket protocol.
To change this situation, appending some message field into handshake
section to distinguish these incompatible revision'll be required.
 
--
Kensaku KOMATSU

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fumitoshi Ukai (鵜飼文敏)
Sent: Monday, October 18, 2010 4:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [hybi] -03

Thanks for updating! 

-- 
ukai

On Mon, Oct 18, 2010 at 05:15, Ian Fette (イアンフェッティ)
<[email-masked]> wrote:

[1] http://trac.tools.ietf.org/wg/hybi/trac/report/1?asc=1
<http://trac.tools.ietf.org/wg/hybi/trac/report/1?asc=1&sort=ticket&USER=ano
nymous> &sort=ticket&USER=anonymous
[2] http://trac.tools.ietf.org/wg/hybi/trac/ticket/25

---

From: John Tamplin <[email-masked]>
Date: Mon, 18 Oct 2010 07:37:07 -0400

> section to distinguish these incompatible revision'll be required.

I have been one arguing for a header describing the draft revision, but if
we switch to a totally different handshake (such as Adam's proposal), the
server will have to know it is a new handshake before any such header could
be read, so it is less useful than it appears.

Also, since the clients are only going to support one version of the
protocol, the server is the one that has to adapt to whatever the client is
sending.  I don't have any problem with having the server return the draft
version requested by the client to fast-fail the connection if the server
isn't compatible, but again if we change the handshake significantly it
doesn't seem likely to be useful.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: James Graham <[email-masked]>
Date: Mon, 18 Oct 2010 14:27:41 +0200

On 10/18/2010 01:37 PM, John Tamplin wrote:
> On Mon, Oct 18, 2010 at 6:53 AM, Kensaku KOMATSU
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I also agree with Ukai's opinion. I little wondered that including
>     draft revision number into protocol header is suitable on not.
>     But current situation(hard to distinguish these incompatible
>     protocols) is not suitable for testing update version of protocol
>     To change this situation, appending some message field into
>     handshake section to distinguish these incompatible revision'll
>     be required.
>
>
> I have been one arguing for a header describing the draft revision, but
> if we switch to a totally different handshake (such as Adam's proposal),
> the server will have to know it is a new handshake before any such
> header could be read, so it is less useful than it appears.

Yes, I think that instead of worrying about versioning now, we should 
concentrate on finalising the handshake. As long as no one ships the new 
framing with the old handshake, we may end up with no versioning problem 
to solve.

---

From: "Kensaku KOMATSU" <[email-masked]>
Date: Mon, 18 Oct 2010 21:55:55 +0900

Yes, I know that new handshake is specified, my concern below means nothing.
Little concern is that we cannnot test new framing protocol ( it begins with
01, about 2 months before )
in the real world unless new handshake appears. Am I too hasty? 

--
Kensaku KOMATSU

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of James Graham
> Sent: Monday, October 18, 2010 9:28 PM
> To: [email-masked]
> Subject: Re: [hybi] -03
> 
> > I have been one arguing for a header describing the draft revision, 
> > but if we switch to a totally different handshake (such as Adam's 
> > proposal), the server will have to know it is a new 
> handshake before 
> > any such header could be read, so it is less useful than it appears.
> 
> Yes, I think that instead of worrying about versioning now, 
> we should concentrate on finalising the handshake. As long as 
> no one ships the new framing with the old handshake, we may 
> end up with no versioning problem to solve.

---

From: "Kensaku KOMATSU" <[email-masked]>
Date: Mon, 18 Oct 2010 22:03:49 +0900

Sorry, I sent inappropriate words... I think I'm too hasty.  

> Little concern is that we cannnot test new framing protocol ( 
> it begins with 01, about 2 months before ) in the real world 
> unless new handshake appears. Am I too hasty? 
> 
> --
> Kensaku KOMATSU
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of James Graham
> > >     among developers(like me). It will prevent to improve 
> websocket
> > >     protocol.
> we should 
> > concentrate on finalising the handshake. As long as no one 
> ships the 
> > new framing with the old handshake, we may end up with no 
> versioning 
> > problem to solve.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 19 Oct 2010 10:23:41 +1100

On 18 October 2010 23:27, James Graham <[email-masked]> wrote:
> framing with the old handshake, we may end up with no versioning problem to
> solve.

Regardless of how the protocol changes, we already have a versioning
problem to solve.

Servers already see multiple versions out there. We are also trying to
track the drafts, so we are prepared to receive connections from -01,
and -02 clients (even though there are none that I know of yet).
If we change the handshake to CONNECT, this will not solve the problem
for servers. We will still need to support -75, -76, -0[012] etc for
at least a short period of time.

We need a way to determine which draft a client is implementing.

---

From: John Tamplin <[email-masked]>
Date: Mon, 18 Oct 2010 19:44:53 -0400

> at least a short period of time.

The point is that a versioning header that is only read as part of the
handshake doesn't help you determine the handshake method.  That will have
to remain a heuristic, much as it is now.  For example, if we switch to
Adam's proposal, you have to accept a CONNECT method before you can read the
header, so a version in that header doesn't help you know to use the CONNECT
method (and especially if the headers are masked).

Servers already have heuristic methods for determining the version of the
client, and I think at this point we are best served by finishing it up and
declaring a 1.0 quickly so we don't have more intermediate versions to worry
about.