Subject: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

From: [email-masked]
Date: Wed, 1 Sep 2010 15:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

	Title           : The WebSocket protocol
	Author(s)       : I. Fette
	Filename        : draft-ietf-hybi-thewebsocketprotocol-01.txt
	Pages           : 57
	Date            : 2010-09-01

The WebSocket protocol enables two-way communication between a user
agent running untrusted code running in a controlled environment to a
remote host that has opted-in to communications from that code.  The
security model used for this is the Origin-based security model
commonly used by Web browsers.  The protocol consists of an initial
handshake followed by basic message framing, layered over TCP.  The
goal of this technology is to provide a mechanism for browser-based
applications that need two-way communication with servers that does
not rely on opening multiple HTTP connections (e.g. using
XMLHttpRequest or <iframe>s and long polling).

Please send feedback to the [email-masked] mailing list.Note

This draft is meant to reflect changes in direction in the HyBi
working group.  There is not yet consensus on everything in this
draft.  Specifically, details about the framing are still under
discussion, however this draft is much closer to what the group is
discussing than the previous draft.  There have also been proposals
to change the handshake, so the handshake is also not in a final
form.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 1 Sep 2010 15:55:09 -0700

I'd like to give a quick explanation of what has changed in this draft.

This draft was begun by taking the -00 version, not what was referred to as
"draft-ietf-hybi-thewebsocketprotocol-latest". The -latest version had a
number of changes after -00, some of which had been discussed on the list
and some of which hadn't. (You can see the changes at
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt&url2=http://svn.tools.ietf.org/svn/wg/hybi/websocket/draft-ietf-hybi-thewebsocketprotocol-latest)
Many of these changes are editorial (e.g. "the server must not send any
further data to the server" -> "the server must not send any further data to
the client"), but there were also a large number of non-editorial changes,
e.g. to the handshake.

The handshake in -01 is the same as in -00. There are certainly open issues
against the handshake, and I do not mean to dismiss them, they simply are
not addressed in this draft.

The focus of this draft was to provide an updated draft that more closely
reflects the framing that the group seems to be discussing. The framing in
this draft is based on "take vii" that john tamplin sent out, and subsequent
discussion. It is not meant to say "Everyone is happy with this version" but
rather to give us a common document which to reference and base discussion
from. I fully expect that there will be changes.

I am hopeful that we will be able to produce a -02 much more quickly, e.g.
perhaps in 2-3 weeks, that reflects further refinement and consensus that
this group reaches on the mailing list.

On an editorial note, if you diff -00 and -01,
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt&url2=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-01.txt,
you can see the full list of changes. It may look at first glance that there
are significant changes to the handshake sections, I assure you these are
editorial, and you should see that if you look at the text of the handshake
sections itself. The reason it doesn't diff cleanly is that the handshake
was previously split across sections called "Client-side requirements" and
"server-side requirements", while it is now in a section called "Opening
Handshake" with sub-sections for client- and server-side requirements.

-Ian

On Wed, Sep 1, 2010 at 3:45 PM, <[email-masked]> wrote:

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 2 Sep 2010 09:09:30 +1000

Ian,

thanks for this first draft, and I hope it indicates a new phase of
progress for the WG.

I'll be updating Jetty to support this draft immediately, but we have
an issue that there is no version information in the handshake.  Thus
in order to support this version of the draft, I risk breaking support
for previous versions, which is difficult as there are already
deployed experimental applications in the wild, interacting with real
clients with browsers beyond the control of the deployers.

Currently user-agent is not sent, so I can't even use that to
determine what version of the draft to use.

I know a standard version header is not widely accepted, but could we
implementers perhaps agree a temporary header just during this draft
phase. Something like:

  Sec-WebSocket-Draft: 1

Unless there are howls of complaint, I'll implement my server to look
for such a field and to use it as a hint when selecting the parser to
use.

cheers

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 16:14:14 -0700

Please don't add versioning to the protocol.  Versioning is a
anti-pattern for the web.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 2 Sep 2010 09:18:54 +1000

Adam,

my proposal was not to add versioning to the protocol - as I know some
think it is an anti pattern.

I just want to be able to implement the next draft without breaking
all my users that have been working on the last draft.   So my
proposal is only for a draft version to be added by implementers as
non-standard convenience at this time. The lack of a draft version can
be taken to mean the final stable version.

How else do you expect servers to track the drafts and deal with the
various browser implementations out there?

regards

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 16:22:59 -0700

> be taken to mean the final stable version.

You're of course free to implement whatever you like, but I don't
think the working group should sanction a versioning mechanism.

> various browser implementations out there?

No one should be using this protocol for anything that can't receive a
breaking change.

Adam

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 16:14:14 -0700

Adam

---

From: John Tamplin <[email-masked]>
Date: Wed, 1 Sep 2010 19:26:55 -0400

> various browser implementations out there?

The problem is that the framing of v75, v76, v00, and v01 are
incompatible.  If you want to write a server that interoperates with
browsers implementing these drafts (I know at least v75 and v76 are in
the wild), then you have to rely on heuristics to figure out which one
you are talking to.  Even if there isn't a version in the 1.0 spec,
any attempt to get real-world data while the spec is changing means
you either have a version number or you heuristically determine one --
the latter is obviously more prone to error.

I would suggest adding Sec-WebSocket-Draft: 01 to implementations of
this draft, and that header will only be present before the spec is
finalized.

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

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 01 Sep 2010 17:34:35 -0600

> I would suggest adding Sec-WebSocket-Draft: 01 to
this draft, and that header will only be present before the
> spec is
finalized.

Let's at least agree that it shouldn't be a header that looks like something
that we had standardized as a part of the WebSocket protocol.

-- 
Joe Hildebrand
(as individual)

---

From: John Tamplin <[email-masked]>
Date: Wed, 1 Sep 2010 19:36:33 -0400

> No one should be using this protocol for anything that can't receive a

Then how do we get real world data?  Should everyone go modify Firefox
or Chrome themselves and run against only their servers to see how it
works?

---

From: John Tamplin <[email-masked]>
Date: Wed, 1 Sep 2010 19:37:17 -0400

> that we had standardized as a part of the WebSocket protocol.

Fine, all I care about is that I don't have to write code that tries
to guess what version of the draft a remote endpoint is trying to use
to talk to me and hope I get it right.

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 16:42:31 -0700

> or Chrome themselves and run against only their servers to see how it

If you're running an experiment, you should either:

1) Upgrade your clients and servers.
2) Break folks who are using old versions of the protocol.

(or ideally both)

If you can't either upgrade the old code or break the use of the old
code, you'll be calcified into using that version protocol.
Versioning isn't the solution.  Avoiding calcification in the
solution.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 2 Sep 2010 09:52:19 +1000

On 2 September 2010 09:26, John Tamplin <[email-masked]> wrote:

> incompatible.

Tell me about it!

>  If you want to write a server that interoperates with
> you are talking to.

We tried initially just to support v75 waiting for a sane v00, but
users were having problems.  So we switched to v76 and got howls of
despair from v75 users.
So now Jetty supports both and we use the presence of Sec headers to
pick between v75 and v76 implementations.

I don't know of any wide deployments of the server, but I do know that
those experimenting with it have other constraints that prevent them
arbitrarily changing browsers at the same time they upgrade their
servers.

> Even if there isn't a version in the 1.0 spec,

Exactly - currently there is no change in the handshake for 01 draft,
so I will have to inspect the first packet and guess.  Of course that
does not work if the server sends the first packet.

> this draft, and that header will only be present before the spec is

thanks!

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 2 Sep 2010 09:54:02 +1000

> 2) Break folks who are using old versions of the protocol.

I'm not running the experiment.
I'm providing infrastructure to many different organizations and
developers that are running the experiments.
Some of them are using real users in their experiments.

There is no single point of control.

regards

---

From: John Tamplin <[email-masked]>
Date: Wed, 1 Sep 2010 19:56:03 -0400

> Versioning isn't the solution.  Avoiding calcification in the

If the clients are the general public, it is not feasible to have them
all upgrade at the same time.  If you want to test a big service, you
can't afford to break people running older browsers.  So your solution
boils down to, test only in controlled environments which means no
real world experience.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 1 Sep 2010 17:00:25 -0700

> anti-pattern for the web.

FTR, that statement is false.  There is a very small group of
inexperienced developers that think client-side rendering of
uncontrolled content somehow defines universal principles for
all software engineering.  The rest of us use whatever techniques
we can to reduce entropy.  Network protocols, in particular,
should always have a version number to distinguish them from
other similar protocols that might appear in the same context.

Both HTTP and Waka have their version in the first line of
every message, and I can assure you that the Web would not have
survived without it.

....Roy

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 1 Sep 2010 16:37:59 -0700

+1. Adam, I share your concerns about versions on the web, but the reality
is there is no other way right now. Suggestions welcome as to alternatives.

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 16:14:14 -0700

Adam

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 2 Sep 2010 00:22:11 +0000

+1. I’m all for a version as part of the protocol itself, but recognize that the discussion right now is limited to a versioning field only during draft stage.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Fette (????????)
Sent: Wednesday, September 01, 2010 4:38 PM
To: John Tamplin
Cc: hybi
Subject: Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

+1. Adam, I share your concerns about versions on the web, but the reality is there is no other way right now. Suggestions welcome as to alternatives.

On Sep 1, 2010 4:27 PM, "John Tamplin" <[email-masked]<mailto:[email-masked]>> wrote:
> On Wed, Sep 1, 2010 at 7:18 PM, Greg Wilkins <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Sep 2010 07:19:29 +0200

> every message, and I can assure you that the Web would not have

I would add that protocol naming and versioning is also an efficient
way to protect against cross-protocol attacks, which is regularly
brought to the table here... If SMTP required a version on its first
line instead of ignoring all unparsable lines, we would not be looking
for ways to prevent a web client from sending emails over SMTP through
POST requests.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Sep 2010 07:20:42 +0200

> to talk to me and hope I get it right.

Let's use something like "X-WebSocket-Experimental: xxx" or something
clear enough on this subject.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Sep 2010 07:25:09 +0200

> Versioning isn't the solution.  Avoiding calcification in the

Adam, I disagree. We're running an experimentation and we want to get
measurable results. This experimentation consists in :
  - getting server-side implementations
  - getting client-side implementations
  - see how they interoperate

If we state that every upgrade will break, noone will want to make the
first move. Browsers will wait for servers to be ready to support it,
and servers will wait for browsers to be ready. With a version, you can
change the servers first, and decide to break support for the old version
as soon as the browsers have support for the new protocol (eg: 1-2 weeks
later max). Also, when we get success or failure reports, it's important
to know if this is because clients can't communicate through the internet
or if it is because they're just not updated and don't talk the same
protocol anymore (in which case these samples must be dropped).

Willy

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 2 Sep 2010 14:35:24 +0900

+1

Aligning implementation is desirable but not realistic for real world
experiment. Welcoming older implementation users to experiment, we can get
more participant and more feedback on WebSocket. People who doesn't care
protocol detail but interested in WebSocket's basic features and API want
not to be blocked by protocol level change, I think.

We implemented some heuristics that look for some -76 (== -00) specific
header in handshake request. Now implementors have no other choice than
using frame inspection to tell -00 and -01 apart as Greg mentioned. At least
in draft stage where we'll publish number of drafts with drastic change as
milestones every time we get consensus on some topic, we should have some
way to tell the version which the client is using explicitly rather than
requiring implementor to adopt such heuristics.

Takeshi

On Thu, Sep 2, 2010 at 09:22, Gabriel Montenegro <[email-masked]>wrote:

> +1. I’m all for a version as part of the protocol itself, but recognize
> that the discussion right now is limited to a versioning field only during
> draft stage.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Ian Fette (????????)
> *Sent:* Wednesday, September 01, 2010 4:38 PM
> *To:* John Tamplin
> *Cc:* hybi
> *Subject:* Re: [hybi] I-D
> Action:draft-ietf-hybi-thewebsocketprotocol-01.txt
>
>
>

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 01 Sep 2010 23:50:50 -0600

> clear enough on this subject.

Well... One of our ADs just wrote this:

http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful

Perhaps Peter would give his opinion on this use of X-?

-- 
Joe Hildebrand

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Sep 2010 08:03:06 +0200

> Perhaps Peter would give his opinion on this use of X-?

I see, but probably that an experiment is precisely the place where it
would have a valid place, as by definition this header will not appear
in any standard : we're sure it quickly disappears when the experiment
ends and the standard is released.

Willy

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Sep 2010 02:07:29 -0400

> for ways to prevent a web client from sending emails over SMTP through

Speaking with my SMTP developer hat on, I don't follow Willy how this 
is a problem.

Many MTA already trap and count unknown commands. If the first command 
is POST, you can reject the client immediately or prevent it from 
going into the next state until it issues QUIT or drop the line for 
excessive out of state commands.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Sep 2010 08:16:13 +0200

> excessive out of state commands.

Well, this is precisely a consequence of the problem I talked about. POST
has never been part of the SMTP protocol, and it's because the SMTP
protocol is prone to such attacks that these checks have been added in
implementations. Maybe some updates to the protocol have since been emitted
to suggest this, but I always had the feeling that these protections were
just good implementers' choices in face of a real threat.

Regards,
Willy

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Sep 2010 03:03:53 -0400

> just good implementers' choices in face of a real threat.

Since this  behavior is no different that a client batching its 
commands with disregard for server responses (not intentional 
pipelining), this has long been mitigated in good MTAs.

The same will be true with websockets - the server always need to be 
control or it will be open to all sorts of issues.

The main thing here is that we are talking about hosting servers and 
whatever protocol is put together, we need to make sure that we don't 
make it hard to resolve the known formulas for threat entry points.

For example, one way to authenticate the WS client is to use IP such 
as it done with POP3-B4-SMTP methods where a POP3 host records an IP 
for another SMTP host to open a time window for SMTP IP-based allow 
relay.

For Websockets, it may work pretty well based on the fact most 
applications will mostly start with a browser client and ws client 
from the same IP. The same idea can be applied here:

    C1: HTTP request (possibly start HTTP or Cookie AUTH login)
    S2: HTTP page is served. IP recorded (optional TTL)
    C3: WS Client begin WS open and handshake
    S4: WS Server authenticates recorded IP, continues with handshake

S2 MAY opens a limited time window (TTL) for the 2nd session to 
appear.   It helps resolve the unsolicited WS client request issue for 
servers that expect WS clients to begin with an HTTP server prepared 
client.

Lets keep in mind something here folks - the mindset has changed to 
even allowing a TCP socket connection to be part of the browser (and 
many of the HTML5 aspect with LOCAL I/O).

Its taken a long time to even view this as "acceptable" but that 
should not be a taken lightly or become a reason to relax with all the 
security concerns.  Its too easy to fall trap in this open generation 
of meshed connections.

If we fail with that, WEBSOCKETS will be turned off which is something 
a QA conscious browser will probably soon need to add to its user 
setup interface in the same way Javacript can be still be turned off. 
  If not done right, expect the NoWebSocket plug-ins to appear.

---

From: "Simon Pieters" <[email-masked]>
Date: Thu, 02 Sep 2010 12:42:40 +0200

> not addressed in this draft.

Some of those changes were in response to feedback from me (mostly sent to  
whatwg). I was happy with the changes Ian Hickson made. What's the plan?  
Is there something I should do if I want those changes in?

Cheers,
-- 
Simon Pieters
Opera Software

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Sep 2010 11:44:20 +0100

>Perhaps Peter would give his opinion on this use of X-?
As somebody who discussed this with Peter, I think reserving a new 
header for this is fine and I agree that it shouldn't be a X- header.

---

From: James Graham <[email-masked]>
Date: Thu, 02 Sep 2010 13:47:51 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-01.txt

A few initial comments:

The framing sections seem to have a lot of SHOULDs. This is worrying as 
SHOULD-level conditions can't really be tested (it is not an error to 
violate them) and can be a source of interoperability problems. I would 
prefer that we make all behaviour mandatory unless there is a good 
reason to do otherwise.

Some specific clauses seem problematic. For example:

"""A receiver MUST be prepared to accept arbitrarily fragmented
       messages, even if the sender sent the message in a single frame."""

"be prepared to accept" seems like poor wording. I would just say 
"Clients and servers MUST support recieving both fragmented and 
unfragmented messages". The clause "even if the sender sent the 
message..." seems odd because it is not clear how the recipient can know 
how the message is originally sent. In any case it seems redundant. This 
whole clause could be avoided with normative processing requirements 
that require support for fragmented and unfragmented messages (see below).

"""Ping

       Upon receipt of a Ping message, an endpoint SHOULD send a Pong
       response as soon as is practical.  The Pong response MUST contain
       the payload provided in the Ping message, though an implementation
       MAY truncate the message at an implementation-defined size which
       MUST be at least 8 _(TBD)_ bytes."""

It seems simpler and less error prone to require truncation always in 
case servers come to depend on the behaviour of specific implementations 
here.

"""      Ping frames MAY be sent as a keep-alive mechanism, but if so 
the interval SHOULD be configurable."""

I have no idea what this SHOULD is trying to require. Is it supposed to 
be a requirement on browser UI? On server implementations? Something 
else? In any case, we can't really require that things are configurable.

"""Close:

       Upon receipt of a close frame, an endpoint SHOULD send a Close
       frame to the remote recipient, if it has not already done so,
       deliver a close event to the application if necessary, and then
       close the WebSocket."""

It is not clear what the scope of the SHOULD here is. Since this is 
nested inside a MUST clause I guess "and then close the connection" is 
supposed to be a requirement. I'm not sure why sending the close frame 
is "SHOULD". I don't think it is necessary to talk about "deliver[ing] a 
close event to the application" since the interaction between the 
application and the protocol is for the application to determine. For 
the specific case of the JS API we just need to ensure we use the right 
terminology so that the description in the API document is correct (i.e. 
this needs to match section 7.3 of the protocol draft and section 5 of 
the API draft).

There seems to be a general lack of processing requirements. I don't 
know if this is just something that is missing from the first draft, but 
without such requirements there are a lot of missing details. For 
example it is unclear what happens if the first frame a client receives 
has opcode=0 (aside: it seems like we can design around this particular 
problem by e.g. ditching opcode=0 and just ignoring opcode after the 
first frame in a fragment). It is also not defined what should happen if 
any of the reserved bits are set or if the opcode is in the reserved 
range. All of these things are essential for interoperable implementations.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Sep 2010 14:04:33 +0200

On 02.09.2010 13:47, James Graham wrote:
 > ...

Nothing stops you from testing them; you just need to either state that 
you reported SHOULD failures as violations, or need to report different 
compliance levels.

Best regards, Julian

---

From: Olli Pettay <[email-masked]>
Date: Thu, 02 Sep 2010 17:18:27 +0300

On 09/02/2010 02:37 AM, Ian Fette (イアンフェッティ) wrote:
> +1. Adam, I share your concerns about versions on the web, but the
> reality is there is no other way right now. Suggestions welcome as to
> alternatives.

Couldn't web applications use different subprotocols for different
versions of the web socket protocol.
That wouldn't be the nicest solution, but could work
well enough while we're trying to get some stable protocol.

-Olli

(I haven't read properly the current draft, but the framing looks too
  complicated. I'll send comments once I've reviewed the draft properly.)

>  > [email-masked] <mailto:[email-masked]>

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 2 Sep 2010 09:24:58 -0700

2010/9/2 Simon Pieters <[email-masked]>

> On Thu, 02 Sep 2010 00:55:09 +0200, Ian Fette (イアンフェッティ) <
> [email-masked]> wrote:
>
> whatwg). I was happy with the changes Ian Hickson made. What's the plan? Is
> there something I should do if I want those changes in?
>
> Cheers,
>

IMO best thing would be to send an email to this list explaining what the
change is, and why it was needed. I don't want to lose these changes, I just
want to make sure they are discussed on this list.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 2 Sep 2010 09:50:55 -0700

James -

Good feedback, thank you. FWIW I agree with what you said below, but I
expect that we will flush out details once we have agreement on the base
framing. In putting this together my primary concern was to get an updated
draft that reflected the recent framing discussions so that we can settle
that issue. Once we have some reasonable level agreement that yes, this
framing is correct, then I think we can fully specify (with MUSTs) behaviour
in all of the circumstances you mention. However, it's a bit like trying to
discuss whether you want the car in red or black when your spouse is trying
to decide between a prius and a F150 -- certain things have to settle down
first :)

-Ian

On Thu, Sep 2, 2010 at 4:47 AM, James Graham <[email-masked]> wrote:

> prefer that we make all behaviour mandatory unless there is a good reason to
> do otherwise.
>
> "be prepared to accept" seems like poor wording. I would just say "Clients
> and servers MUST support recieving both fragmented and unfragmented
> messages". The clause "even if the sender sent the message..." seems odd
> because it is not clear how the recipient can know how the message is
> originally sent. In any case it seems redundant. This whole clause could be
> avoided with normative processing requirements that require support for
> fragmented and unfragmented messages (see below).
>
> """Ping
>
> It seems simpler and less error prone to require truncation always in case
> servers come to depend on the behaviour of specific implementations here.
>
> """      Ping frames MAY be sent as a keep-alive mechanism, but if so the
> interval SHOULD be configurable."""
>
> I have no idea what this SHOULD is trying to require. Is it supposed to be
> a requirement on browser UI? On server implementations? Something else? In
> any case, we can't really require that things are configurable.
>
> """Close:
>
> It is not clear what the scope of the SHOULD here is. Since this is nested
> inside a MUST clause I guess "and then close the connection" is supposed to
> be a requirement. I'm not sure why sending the close frame is "SHOULD". I
> don't think it is necessary to talk about "deliver[ing] a close event to the
> application" since the interaction between the application and the protocol
> is for the application to determine. For the specific case of the JS API we
> just need to ensure we use the right terminology so that the description in
> the API document is correct (i.e. this needs to match section 7.3 of the
> protocol draft and section 5 of the API draft).
>
>
> There seems to be a general lack of processing requirements. I don't know
> if this is just something that is missing from the first draft, but without
> such requirements there are a lot of missing details. For example it is
> unclear what happens if the first frame a client receives has opcode=0
> (aside: it seems like we can design around this particular problem by e.g.
> ditching opcode=0 and just ignoring opcode after the first frame in a
> fragment). It is also not defined what should happen if any of the reserved
> bits are set or if the opcode is in the reserved range. All of these things
> are essential for interoperable implementations.
>

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 2 Sep 2010 09:53:30 -0700

>  complicated. I'll send comments once I've reviewed the draft properly.)
Subprotocols are intended to be an application level indication, and IMO
should affect base framing. This seems to be conflating issues.

Also, in addition to reviewing the draft, I would ask that you try to review
the comments that led up the draft being what it is, otherwise we are likely
to just revisit old discussions.

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 2 Sep 2010 16:57:25 +0000

The real issue here is that MUST is the right keyword if something is required for interoperability. A SHOULD means you are recommended to do a certain thing, but you may depart from that recommendation if you know better or have a good reason. MAY is for optional stuff. 

My take on it is that the basic framing is absolutely a MUST. Optional stuff like multiplexing or compression are MAYs (when and if we get to them). Fragmentation support sounds like a SHOULD.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Julian Reschke
> Sent: Thursday, September 02, 2010 5:05 AM
> To: James Graham
> Cc: [email-masked]
> > The framing sections seem to have a lot of SHOULDs. This is worrying
> > as SHOULD-level conditions can't really be tested (it is not an error
> > to violate them) and can be a source of interoperability problems. I
> > would
>  > ...
> 
> Nothing stops you from testing them; you just need to either state that you
> reported SHOULD failures as violations, or need to report different compliance
> levels.
> 
> Best regards, Julian

---

From: John Tamplin <[email-masked]>
Date: Thu, 2 Sep 2010 13:19:12 -0400

> prefer that we make all behaviour mandatory unless there is a good reason to

I think we can tighten those up as we get consensus.  As an example,
there were people that wanted keep-alives, and people that didn't.
The language in Ping/Pong is intended to mean that those who want them
can have them, while the ones who don't, don't.  I agree it would be
better to have fewer options left up to the implementation, but I
think we need more debate to get there.

> fragmented and unfragmented messages (see below).

So, the case I was thinking of was someone writing the JS code for
their app and their own stand-alone server.  Without some statement to
that effect, they might assume that if they send a single message the
server will receive it in a single frame, but the browser or some
intermediary might decide to fragment it anyway.  I am open to
different ways of wording it, but I think there needs to be some
clarification that just because a message was sent in one fragment
doesn't meant it will stay that way.

> servers come to depend on the behaviour of specific implementations here.

So what should that size be?  Also, the simplest case is you already
have the ping frame in memory, and you just immediately send it back
out -- it would actually be more work to truncate it first.

> I have no idea what this SHOULD is trying to require. Is it supposed to be a
> requirement on browser UI? On server implementations? Something else? In any
> case, we can't really require that things are configurable.

See above.  If we can get agreement on what a keep-alive mechanism
should look like (which I think would be good so that they could be
aggregated on muxed connections or rate-limited on mobile networks,
for example), then I think it would be great to specify exactly what
that happens.

The attempt here was to capture that part of the framing which we
appear to have agreed on, and use that as a base for finishing the
rest of it.

> protocol draft and section 5 of the API draft).

I don't know if it is reasonable to require the close frame in all
cases -- some implementations may not make it easy to close inbound
while keeping outbound traffic alive to send the close frame, or the
architecture makes it awkward.  The original closer has to be prepared
to not get a response anyway, in case the connection goes down.

Regarding the application layer, it seems like you would want to
define the interaction between the WebSocket layer and the application
layer, but I agree perhaps the discussion of framing isn't the right
place for it.

> For example it is unclear what happens if the first frame a client receives has
> opcode=0 (aside: it seems like we can design around this particular problem by
> e.g. ditching opcode=0 and just ignoring opcode after the first frame in a
> fragment).

That seems ripe for interoperability problems -- some implementations
may wind up just using the opcode of the last frame if they are all
sent the same, and an attacker could take advantage of differing
implementations to sneak some data past a filtering intermediary by
having a different opcode on an intermediate frame.  It seems better
to avoid those problems by mandating a Continuation opcode, and it
also gets you useful error checking (similar to when two bits were
used for fragmentation support).

> It is also not defined what should happen if any of the reserved

Ok.  I would suggest mandating that any framing error, such as a
non-Continuation opcode on a non-intitial frame, using reserved bits
if no extension was negotiated which defined them, etc, the connection
should simply be dropped.  Maybe we want to have a Control frame for
"Framing error", which might be part of the Close frame, or maybe just
drop it.

---

From: John Tamplin <[email-masked]>
Date: Thu, 2 Sep 2010 13:22:10 -0400

> should affect base framing. This seems to be conflating issues.

Did you mean "should not affect"?  If not, I think I am
misunderstanding your point.

---

From: John Tamplin <[email-masked]>
Date: Thu, 2 Sep 2010 13:23:18 -0400

> My take on it is that the basic framing is absolutely a MUST. Optional stuff like multiplexing or compression are MAYs (when and if we get to them). Fragmentation support sounds like a SHOULD.

I think fragmentation has to be optional for the sender, and mandatory
for the receiver.  So, I think that is a sender MAY fragment a message
and a receiver MUST be prepared to receive fragmented messages.

---

From: Olli Pettay <[email-masked]>
Date: Thu, 02 Sep 2010 20:31:09 +0300

On 09/02/2010 07:53 PM, Ian Fette (イアンフェッティ) wrote:
> On Thu, Sep 2, 2010 at 7:18 AM, Olli Pettay <[email-masked]
> <mailto:[email-masked]>> wrote:
>

I understand what subprotocols are meant for, but while we're trying to
stabilize the protocol, subprotocols could be used for versioning too.

>
> Also, in addition to reviewing the draft, I would ask that you try to
> review the comments that led up the draft being what it is, otherwise we
> are likely to just revisit old discussions.

Yeah, I know that there is a risk that I will complain about things what
others have complained too, and what others like about.
In general it is not clear to me why we have to change framing so much.
The old hixie-style framing allow all sorts for extensions. There are
plenty of bits left for different kinds of frame types.

(And for things like multiplexing shared workers some
  people have just said that it doesn't work without even trying.)

-Olli

>
>
>
>
>         On Sep 1, 2010 4:27 PM, "John Tamplin" <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          > On Wed, Sep 1, 2010 at 7:18 PM, Greg Wilkins
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Sep 2010 19:39:07 +0200

> The real issue here is that MUST is the right keyword if something is required for interoperability. A SHOULD means you are recommended to do a certain thing, but you may depart from that recommend…

"may know better" certainly isn't an excuse.

> My take on it is that the basic framing is absolutely a MUST. Optional stuff like multiplexing or compression are MAYs (when and if we get to them). Fragmentation support sounds like a SHOULD.

I agree that there probably shouldn't be any wiggle room wrt framing.

Best regards, Julian

---

From: Scott Ferguson <[email-masked]>
Date: Thu, 02 Sep 2010 10:55:45 -0700

> My take on it is that the basic framing is absolutely a MUST. Optional stuff like multiplexing or compression are MAYs (when and if we get to them). Fragmentation support sounds like a SHOULD.

Fragmentation is a MUST, based on past experience with non-browser 
clients and HTTP.

Since a non-browser client might only send small queries, but receive 
large data, a lazy implementation with would skip fragmenting support 
entirely (because they never need to send fragments) if it's SHOULD, 
because it's slightly easier for them to force the server to buffer all 
data, which defeats the whole point of fragmenting. Since the receiving 
code for fragmentation is actually small, allowing that kind of laziness 
is harmful.

There's no requirement that anyone send fragments, of course, but they 
MUST be able to receive fragmented data, or server writers will go insane.

-- Scott

---

From: John Tamplin <[email-masked]>
Date: Thu, 2 Sep 2010 13:40:49 -0400

> stabilize the protocol, subprotocols could be used for versioning too.

So what if you want to experiment with an application subprotocol?  If
the framing is altered based on the subprotocol, then the application
can't use subprotocols itself.

> plenty of bits left for different kinds of frame types.

Well, the first problem is it doesn't support fragmentation, which is
a problem given that has been accepted as a requirement.  Second, it
uses two different types of framing for text and binary data, and many
negative opinions of having two types of framing were expressed here.
Finally, the only possible method of extension would be to define
nested opcodes, and there have been many discussions here about the
virtue of that choice relative to others.  The point of the current
framing is that it answers most of the objections that have been
raised while retaining the flexibility to define the various extension
mechanisms that have been proposed on top of it.  That allows us to
agree on the base framing, in such a way that those who don't ever
want to handle extensions can just refuse to negotiate them and ignore
them, and then those who do care can debate the merits of different
extension mechanisms.

>  people have just said that it doesn't work without even trying.)

How can writing shared workers ever handle the case of mutliplexing
traffic in different apps?  Or aggregating traffic across an expensive
wireless link, which will then get split on the other side?  Even if
shared workers can be used to solve some of the problems multiplexing
solves, it can't solve all of them and IMHO is more complex rather
than just implementing it once in the framing layer.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 2 Sep 2010 10:27:59 -0700

Yes, sorry. Should NOT affect.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 2 Sep 2010 10:34:01 -0700

> plenty of bits left for different kinds of frame types.

I really suggest you read the archive before trying to re-hash debates that
have gone on for hundreds of email messages

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 2 Sep 2010 20:25:53 +0200 (CEST)

On Wed, 1 Sep 2010, Adam Barth wrote:

> Please don't add versioning to the protocol.  Versioning is a anti-pattern 
> for the web.

We've seen this mentioned before on this list but without a lot of 
clarifications and I'm curious:

What are the other transfer protocols for which versioning have failed so 
significantly that versioning in protocols can be called an anti-pattern?

Or isn't it so that it truly is an anti-pattern for the *web* (with the 
emphasis added on the web word) and we're not really doing web here, we're 
discussing a transfer protocol.

HTTP is the primary "web protocol" and AFAIK, its versioning is usually not 
considered a failure.

-- 

  / daniel.haxx.se

---

From: Tim Bray <[email-masked]>
Date: Thu, 2 Sep 2010 11:42:16 -0700

Versioning requres you to make all sorts of REALLY HARD choices, and runs
the risk of imposing really onerous costs on implementors.  Thus, you need
to be really convinced that there are really significant benefits before you
embark on this difficult and risky course of action.  -Tim

---

From: John Tamplin <[email-masked]>
Date: Thu, 2 Sep 2010 14:50:00 -0400

> embark on this difficult and risky course of action.  -Tim

Not versioning requires an implementor to make the same really hard
choices, plus the added complexity of trying to figure out which
version of the protocol the other version is speaking.

Once we get to the final version of the spec, I am fine with leaving
out a formal version identifier, and then when we get to the point of
wanting to add some non-backwards-compatible feature we can have the
discussion about adding versioning then.

However, I remain totally convinced that we have to have some version
identifier in the draft protocol, so we can tell different versions of
the draft apart.  We already have mutually incompatible
implementations in the wild, and having to come up with heuristics to
detect each new version that might be out there is going to get more
and more problematic.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 02 Sep 2010 19:52:30 +0100

> embark on this difficult and risky course of action.  -Tim
To put it another way, versioning is for flag days, whereas feature  
negotiation is for, well, negotiating features.

An example of a protocol with both is XMPP. It has a version, which  
is always 1.0. It also has stream features for peer-to-peer feature  
negotiation.

Jabber, its predecessor, had no version - but it also lacked the  
feature negotiation. Essentially, XMPP's version indicates to the  
receiver that it's okay to announce what features you offer.

So in our release protocol, I'd say we SHOULD NOT have a version, but  
we MAY have a static, never to be changed, version.

For now, though, when we're quite likely to want to change our  
feature negotiation mechanisms, we probably MUST have a version.

The key item is not that versions are bad, but that *changing* them  
is.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Sep 2010 14:52:48 -0400

+1

Tim Bray wrote:
> ------------------------------------------------------------------------
>

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Sep 2010 15:00:39 -0400

Ian, 

Thanks for the new draft! I think it is great that we all have a
document to focus on moving forward; this is a big help. 

Websockets Group,

I've read through the document and I wanted to provide a list of mostly
editorial-style updates to the portions that deal with framing. They are
generally not meant to change the substance of the document but rather
to improve clarity and help us focus on the real issues. Very much a
refinement of what Ian achieved with -01. 

However, some of the changes do go beyond syntax changes (see control
messages) in order to address  some basic problems. But any really
significant changes in meaning will go into separate email threads.

There is good material in section 1 and especially 4 and my goal is to
especially strengthen the normative material in section 4 and get it at
least a little closer to ietf-standards speak. 

Like your revision, I have limited myself to the framing considerations.
Basically that's section 4 and parts of section 1. The other stuff
obviously still needs to be addressed.

Each of my proposed changes is described below, broken apart by
subsection. I've also attached copies of the draft with my edits
included and a diff between that and -01, so people can easily review
them.

-Patrick (proposed changes below)

Section 1.2 - Protocol Overview. There is good normative content here
that is too detailed for the overview and that should be in section 4
instead (as it is wasted in the non-normative section 1).

  * Change the text "On the network layer, a message may be represented
as one or more frames." to be "The websocket message does not
necessarily correspond to any network layer framing.".. This is more
correct as the network layer may coalesce as well as fragment.
  
  * strike the paragraph beginning "to close" as it too low level of a
detail to be considered part of the overview and is redundant to the
normative text.

  * For similar reasons, strike the paragraph "the protocol is designed"
but add the more summary oriented sentence "This version of the protocol
defines six frame types and leaves ten reserved for future use." to the
end of the section 1.2 paragraph that begins "Data is sent". The
original sentence doesn't reflect the current allocation of op codes.

  * move the ABNF portion to normative section 4.2.

Section 4.1 - normative Data Framing Overview

  * strike the sentence "The base framing protocol is deliberately kept
simple so that simple implementations may ignore advanced features."
There is no definition of simple implementations, no definition of
advanced features, and no definition of what ignore might mean in this
context. What is an implementor to do with it? :)..  I personally don't
think we need the text at all, but if we want it move it to a
non-normative section.

  * update the remainder of 4.1 to standards-speak: "In the absence of
extensions negotiated during the opening handshake (Section 5), all
reserved bits MUST be 0 and reserved opcode values MUST NOT be used."..
actually this probably belongs somewhere other than the overview.

  * Add to that 4.1 paragraph the text "A data frame MAY be transmitted
by either the client or the server at any time after handshake
completion and before that host has generated a close message." That
probably means we need a normative definition of client and server
somewhere - but I think this is an important thing to say in a place
other than section 1.

Section 4.2 - 

  * as noted the ABNF from 1.2 is moved here

  * Payload length - before "The payload length is" .. insert the
sentence "Multibyte length quantities are expressed in network byte
order." - that's an impt omission.

  * I had trouble understanding where the extension data length came
from. I now (think) I understand that it is part of the extension
definiton or negotiation itself. I changed the Extension Data definition
to reflect this requirement more clearly:

      "The extension data is 0 bytes unless there is a reserved op-code
      or reserved bit present in the frame which indicates an
      extension. Any extension MUST specify the length of the
      extension data and its use MUST be negotiated during the
      handshake."

Section 4.3 - Fragmentation

 * Change the paragraph that begins "a sender MAY arbitrarily fragment a
single message (which allows generation of dynamic content without
having to buffer the data in order to count it)." to read more simply "A
sender MAY create fragments of any size for non control messages." If we
need to explain why fragments are important, which I don't think we need
to do, that can live outside of normative section 4.

  * Change the paragraph "A receiver MUST be prepared to accept
arbitrarily fragmented messages, even if the sender sent the message in
a single frame." to the more direct "A receiver MUST support receipt of
fragmented messages.". .. I assume the text about "sender sent .. in
single frame" is referring to intermediaries, but it can't really happen
like that - the intermediary is a sender too. To express the concept we
would have to define something like origin-server/user-agent which are
subsets of senders.. but I really don't see why this paragraph needs the
concept at all.

  * Change the paragraph "An intermediary MAY fragment .." to read "An
intermediary MAY change the fragmentation of a message if the message
uses an opcode and reserved bit values known to the intermediary."  This
change allows coalescing as well as fragmentation, and using the "if"
keeps us out of the awkward "may.. except must not" language the text
was using, and it restricts the section 4.3 requirement to only deal
with fragmentation.

Section 4.4 - Control Frames

I've done some more significant cleanups here that go a bit beyond the
editorial. Specifically I want to include some of James Graham's
concerns.

As drafted a ping and pong are meant to be paired together via their
content.. but the pong is allowed to truncate the content but isn't
given any mechanism to indicate that it has done so.. in light of that
how can the pinger determine if there is a match? If those truncated
bytes aren't relevant to the match, why did it send them in the first
place? My answer to that is to disallow truncation but limit the message
size to the tiny 125 byte frame size. If people want to argue for a
larger but still reasonable constant I don't have a problem with that.
Furthermore the draft made responding to the ping optional (SHOULD
level) which really makes it kind of useless as a keep-alive.. so I
changed that to MUST respond, but SHOULD do it soonish. (see text).

We've been calling them control frames, not control messages, so I
assume that means they shouldn't be fragmented and I made that a
requirement. The alternative is to try and consistently call them
control messages. Personally, I don't see a reason to let them be
fragmented into multiple frames.

With that being said - this is the proposed replacement for section 4.4:

=============

4.4.  Control Frames

   Control frames have opcodes of 0x01, 0x02, or 0x03. They are used
   to communicate state about the websocket.

   All control frames MUST be 125 bytes or less in length and MUST NOT
   be fragmented.

4.4.1 Close

   The Close message contains an opcode of 0x01.

   The application MUST NOT send any more data messages after
   sending a close message.

   A recevied close message is deemed to be an acknowledgement if the
   message body matches the body of a close message previously sent by
   the receiver. Otherwise the close message is a close initiated by
   the sender.

   Upon receipt of an initiated close the endpoint MUST send a close
   acknowledgment. It should do so as soon as is practical.

   The websocket is considered fully closed when an endpoint has either
   received a close acknowledgment or sent a close acknowledgment.

4.4.2 Ping

   The Ping message contains an opcode of 0x02.

   Upon receipt of a Ping message, an endpoint MUST send a Pong
   message in response. It SHOULD do so as soon as is practical. The
   message bodies of the Ping and Pong MUST be the same.

4.4.3 Pong

   The Pong message contains an opcode of 0x03.

   Upon receipt of a Ping message, an endpoint MUST send a Pong
   message in response. It SHOULD do so as soon as is practical. The
   message bodies of the Ping and Pong MUST be the same.

======================

Section 4.5 Data Frames

  * replace "not listed above" with "not listed in Section 4.4"
  
  * strike the paragraph "Additional data frame types" .. its just not
necessary for this part of the normative document and is redundant with
the overview section which describes future use.

Section 4.7 Extensibility

With respect to section 4 framing there isn't a lot to say about
extensibility. I replaced the existing section 4.7 text with this:

"   The endpoints MUST negotiate the use of any extensions during the
   handshake. This specification provides opcodes 0x6 through 0xF, the
   extension data field, and the frame-rsv1, frame-rsv2,
   frame-rsv3, and frame-rsv4 bits of the frame	header for use by
   extensions.   "

--- draft-ietf-hybi-thewebsocketprotocol-01.txt	2010-09-02 13:47:44.106637493 -0400
+++ hybi-01-mcmanus.01	2010-09-02 14:49:01.166637408 -0400
@@ -379,8 +379,8 @@
    "messages".  A message is a complete unit of data at an application
    level, with the expectation that many or most applications
    implementing this protocol (such as web user agents) provide APIs in
-   terms of sending and receiving messages.  On the network layer, a
-   message may be represented as one or more frames.
+   terms of sending and receiving messages.  The websocket message
+   does not necessarily correspond to any network layer framing.
 
    Data is sent on the wire in the form of frames that have an
    associated type.  Broadly speaking, there are types for textual data,
@@ -396,7 +396,8 @@
    is left up to the application), and control frames, which are not
    intended to carry data for the application, but instead for protocol-
    level signalling, such as to signal that the connection should be
-   closed.
+   closed. This version of the protocol defines six frame types and
+   leaves ten reserved for future use.
 
    The WebSocket protocol uses this framing so that specifications that
    use the WebSocket protocol can expose such connections using an
@@ -404,42 +405,6 @@
    specifications to implement buffering and piecing together of
    messages manually.
 
-   To close the connection cleanly, a control frame is sent from one
-   peer to ask that the other peer close the connection.  Details are
-   specified in Section 7.
-
-   The protocol is designed to support other frame types in future.
-   Currently only four frame types are defined -- continuation (used for
-   fragmented messages), control frames, text frames, and binary data
-   frames.  Eight frame types are reserved for future use, and four
-   frame types are reserved for private use.
-
-   This wire format for the data transfer part is described by the ABNF
-   given in detail in Section 4.  A high level overview of the framing
-   is given in the following figure.  [RFC5234]
-
-
-      0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-------+-+-------------+-------------------------------+
-     |M|R|R|R| opcode|R| Payload len |    Extended payload length    |
-     |O|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
-     |R|V|V|V|       |V|             |   (if payload len==126/127)   |
-     |E|1|2|3|       |4|             |                               |
-     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
-     |     Extended payload length continued, if payload len == 127  |
-     + - - - - - - - - - - - - - - - +-------------------------------+
-     |                               |         Extension data        |
-     +-------------------------------+ - - - - - - - - - - - - - - - +
-     :                                                               :
-     +---------------------------------------------------------------+
-     :                       Application data                        :
-     +---------------------------------------------------------------+
-
-   MORE:  1 bit
-
-      Indicates more fragments follow in the current message
-

@@ -449,39 +414,6 @@
 Internet-Draft           The WebSocket protocol              August 2010

-   RSV1, RSV2, RSV3, RSV4:  1 bit each
-
-      Must be 0 unless an extension is negotiated which defines meanings
-      for non-zero values
-
-   Opcode:  4 bits
-
-      Defines the interpretation of the payload data
-
-   Payload length:  7 bits
-
-      The length of the payload: if 0-125, that is the payload length.
-      If 126, the following 2 bytes interpreted as a 16 bit unsigned
-      integer are the payload length.  If 127, the following 8 bytes
-      interpreted as a 64-bit unsigned integer (the high bit must be 0)
-      are the payload length.  The payload length is the length of the
-      Extension data + the length of the Application Data.  The length
-      of the Extension data may be zero, in which case the Payload
-      length is the length of the Application data.
-
-   Extension data:  n bytes
-
-      Only present if an extension is negotiated during the handshake
-      which defines it.  If present, it is included in the total payload
-      length.
-
-   Application data:  n bytes
-
-      Arbitrary application data, taking up the remainder of the frame
-      after any extension data.  The length of the Application data is
-      equal to the payload length minus the length of the Extension
-      data.
-
 1.3.  Opening handshake
 
    _This section is non-normative._
@@ -1125,20 +1057,73 @@
 
 4.1.  Overview
 
-   The base framing protocol is deliberately kept simple so that simple
-   implementations may ignore advanced features.  In the absence of
-   extensions negotiated during the opening handshake (Section 5), all
-   reserved bits must be 0 and no reserved opcode values may be used.
+   In the absence of extensions negotiated during the opening
+   handshake (Section 5), all reserved bits MUST be 0 and reserved
+   opcode values MUST NOT be used.  A data frame MAY be transmitted
+   by either the client or the server at any time after handshake
+   completion and before that host has generated a close message.
 
 4.2.  Base Framing Protocol
 
    The base framing protocol is defined by the following ABNF [RFC5234]:

+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-------+-+-------------+-------------------------------+
+     |M|R|R|R| opcode|R| Payload len |    Extended payload length    |
+     |O|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
+     |R|V|V|V|       |V|             |   (if payload len==126/127)   |
+     |E|1|2|3|       |4|             |                               |
+     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
+     |     Extended payload length continued, if payload len == 127  |
+     + - - - - - - - - - - - - - - - +-------------------------------+
+     |                               |         Extension data        |
+     +-------------------------------+ - - - - - - - - - - - - - - - +
+     :                                                               :
+     +---------------------------------------------------------------+
+     :                       Application data                        :
+     +---------------------------------------------------------------+
+
+   MORE:  1 bit
+
+      Indicates more fragments follow in the current message
+
+   RSV1, RSV2, RSV3, RSV4:  1 bit each
+
+      Must be 0 unless an extension is negotiated which defines meanings
+      for non-zero values
+
+   Opcode:  4 bits
+
+      Defines the interpretation of the payload data
 
+   Payload length:  7 bits
 
+      The length of the payload: if 0-125, that is the payload length.
+      If 126, the following 2 bytes interpreted as a 16 bit unsigned
+      integer are the payload length.  If 127, the following 8 bytes
+      interpreted as a 64-bit unsigned integer (the high bit must be
+      0) are the payload length.  Multibyte length quantities are
+      expressed in network byte order. The payload length is the
+      length of the Extension data + the length of the Application
+      Data.  The length of the Extension data may be zero, in which
+      case the Payload length is the length of the Application data.
 
+   Extension data:  n bytes
 
+      The extension data is 0 bytes unless there is a reserved op-code
+      or reserved bit present in the frame which indicates an
+      extension. Any extension MUST specify the length of the
+      extension data and its use MUST be negotiated during the
+      handshake.
+
+   Application data:  n bytes
+
+      Arbitrary application data, taking up the remainder of the frame
+      after any extension data.  The length of the Application data is
+      equal to the payload length minus the length of the Extension
+      data.

@@ -1245,65 +1230,61 @@
       be decided whether they be fragmented (which would require keeping
       a stack of "in-progress" messages)._
 
-   o  A sender MAY arbitrarily fragment a single message (which allows
-      generation of dynamic content without having to buffer the data in
-      order to count it).
-
-   o  A receiver MUST be prepared to accept arbitrarily fragmented
-      messages, even if the sender sent the message in a single frame.
-
-   o  An intermediary MAY fragment a message arbitrarily, except that it
-      MUST NOT fragment or otherwise modify any message with any
-      reserved bits set or using any reserved opcode, unless it observed
-      the negotiation of an extension which it understands and which
-      defines the interpretation of those values.
+   o  A sender MAY create fragments of any size for non control messages.
+
+   o  A receiver MUST support receipt of fragmented messages.
+
+   o  An intermediary MAY change the fragmentation of a message if the
+      message uses an opcode and reserved bit values known to the intermediary.
+
 
 4.4.  Control Frames
 
-   The Close (0x01), Ping (0x02), and Pong (0x03) frames are contol
-   frames -- they do not supply data to the ultimate endpoint, but
-   instead are used to carry out tasks related to the WebSocket
-   connection itself.
+   Control frames have opcodes of 0x01, 0x02, or 0x03. They are used
+   to communicate state about the websocket.
 
-   A receiver MUST take the following action upon receiving control
-   frames:
+   All control frames MUST be 125 bytes or less in length and MUST NOT
+   be fragmented.
 
-   Close:
+4.4.1 Close
+ 
+   The Close message contains an opcode of 0x01.
 
-      Upon receipt of a close frame, an endpoint SHOULD send a Close
-      frame to the remote recipient, if it has not already done so,
-      deliver a close event to the application if necessary, and then
-      close the WebSocket.
+   The application MUST NOT send any more data messages after
+   sending a close message.
 
-   Ping
+   A recevied close message is deemed to be an acknowledgement if the 
+   message body matches the body of a close message previously sent by
+   the receiver. Otherwise the close message is a close initiated by
+   the sender.
 
-      Upon receipt of a Ping message, an endpoint SHOULD send a Pong
-      response as soon as is practical.  The Pong response MUST contain
-      the payload provided in the Ping message, though an implementation
-      MAY truncate the message at an implementation-defined size which
+   Upon receipt of an initiated close the endpoint MUST send a close
+   acknowledgment. It should do so as soon as is practical.
 
+   The websocket is considered fully closed when an endpoint has either
+   received a close acknowledgment or sent a close acknowledgment.

-Fette                     Expires March 4, 2011                [Page 23]
-
-Internet-Draft           The WebSocket protocol              August 2010
+4.4.2 Ping
 
+   The Ping message contains an opcode of 0x02.
 
-      MUST be at least 8 _(TBD)_ bytes.
+   Upon receipt of a Ping message, an endpoint MUST send a Pong
+   message in response. It SHOULD do so as soon as is practical. The
+   message bodies of the Ping and Pong MUST be the same.
 
-      Ping frames MAY be sent as a keep-alive mechanism, but if so the
-      interval SHOULD be configurable.
+4.4.3 Pong
+   
+   The Pong message contains an opcode of 0x03.
 
-   Pong
+   Upon receipt of a Ping message, an endpoint MUST send a Pong
+   message in response. It SHOULD do so as soon as is practical. The
+   message bodies of the Ping and Pong MUST be the same.
 
-      If a Pong message is received without a matching Ping message
-      being sent, an endpoint MUST drop the connection.  Otherwise, the
-      endpoint SHOULD update any liveness timer it may have for the
-      connection.
 
 4.5.  Data Frames
 
-   All frame types not listed above are data frames, which transport
+   All frame types not listed in Section 4.4 are data frames, which transport
    application-layer data.  The opcode determines the interpretation of
    the application data:
 
@@ -1316,9 +1297,6 @@
       The payload data is arbitrary binary data whose interpretation is
       solely up to the application layer.
 
-   Additional data frame types will be defined in extensions or in a
-   subsequent version of the protocol.
-
 4.6.  Examples
 
    _This section is non-normative._
@@ -1357,42 +1335,11 @@
 
 4.7.  Extensibility
 
-   Extensions will be defined which extend the base protocol, but only
-   if their use is negotiated during the handshake.  The following
-   mechanisms will be used for extension:
-
-   o  Extension data may be placed in the payload before the application
-      data.
-
-   o  Reserved bits can be allocated for per-frame needs.
-
-   o  Reserved opcode values can be defined.
-
-   o  Reserved bits can be allocated to the opcode field if more opcode
-      values are needed.
-
-   o  A reserved bit or an "extension" opcode can be defined which
-      allocates additional bits out of the payload area to define larger
-      opcodes or more per-frame bits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+   The endpoints MUST negotiate the use of any extensions during the
+   handshake. This specification provides opcodes 0x6 through 0xF, the
+   extension data field, and the frame-rsv1, frame-rsv2,
+   frame-rsv3, and frame-rsv4 bits of the frame header for use by
+   extensions.

---

From: John Tamplin <[email-masked]>
Date: Thu, 2 Sep 2010 16:06:07 -0400

Leaving out the suggestions I agree completely with.

> think we need the text at all, but if we want it move it to a

Maybe there needs to be a separate document with the rationale, or perhaps
they can be kept inline in the draft with the understanding that they will
not be present in the final version, but this and other statements were
intended to make clear the rationale for the choice and to alleviate
concerns held by those wanting a simple protocol and those wanting to make
sure their more complex use cases would be covered.

> to do, that can live outside of normative section 4.

This is another case like above, giving the rationale to head-off
objections.  It can go inline annotated as such, a separate non-normative
section collecting all the rationale bits, or a separate document.

> subsets of senders.. but I really don't see why this paragraph needs the

As mentioned in an earlier reply on the list, it was to make clear that even
if someone wrote both the receiver and the sender endpoints, the receiver
must support receiving fragments even if the sender didn't send them.  If it
is sufficiently clear that requiring a receiver to support fragmentation
means even if the sending endpoint (as differentiated from an intermediary)
didn't fragment the message, then I am fine with that.

> changed that to MUST respond, but SHOULD do it soonish. (see text).

The idea was that we require a minimum size for truncation, which would be
sufficient to include an id and/or timestamp.  I would be fine with your
suggestion as well.

> fragmented into multiple frames.

I agree with the general principle of not fragmenting control messages (and
it also solves the problem of interjecting control messages in the middle of
a fragmented message, since you don't have to keep a stack of "open"
messages).  However, I worry if later on we will want to have a control
message that may need to be larger, in which case not being able to fragment
it may cause other problems.

> With that being said - this is the proposed replacement for section 4.4:

With the above caveats, I am fine with your replacement text.

> extensibility. I replaced the existing section 4.7 text with this:

Again, this section was primarily intended to alleviate fears that the base
protocol was not extensible enough to support some of the ideas that have
been discussed.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 2 Sep 2010 22:22:03 +0200

> for another SMTP host to open a time window for SMTP IP-based allow 

IP is often used in POP+SMTP auth because the purpose is to grant a
service to some users during a short period of time, with very little
risk if the match fails.

In web environment, the IP is useless for anything other than logging.
Depending on the environments and web sites, I have observed up to as
much as 5% of the users showing a different IP address at least once
in a session. The most common cases are on sites used from work, because
many companies have large outgoing proxy farms. And for the same reason
you can't rely on that at all because when 1000 users come to your site
via the same IP address, it's a real issue.

And I predict that with IPv6 it will be even worse, because right now
this issue is hidden by the fact that many internet access points are
natted due to IP addresses shortage. But right now it's already common
to see various types of requests pass through different outgoing proxies.
And here, we will certainly have some users showing one (or a few) IP
address(es) for the main HTTP traffic, and another set for the WS traffic.
I'm not even talking about mobile users !

And that's what is really nice with HTTP : it allows such architectures
to reliably work without having to wonder about IP addresses!

Regars,
Willy

---

From: Dave Cridland <[email-masked]>
Date: Thu, 02 Sep 2010 21:35:37 +0100

On Thu Sep  2 08:03:53 2010, Hector Santos wrote:
> For example, one way to authenticate the WS client is to use IP  
> such as it done with POP3-B4-SMTP methods where a POP3 host records  
> an IP for another SMTP host to open a time window for SMTP IP-based  
> allow relay.

That's been long discredited in email circles, and is generally not  
supported, in favour of SMTP AUTH (and preferably a dedicated  
submission service on 587 with SASL and TLS).

The reason it's been discredited is actually because it's in a  
general class of error referred to as "Time of check to time of use".

Dave.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Sep 2010 17:11:13 -0400

Hi John, thanks for reading the long list and providing feedback.

> Maybe there needs to be a separate document with the rationale, [..]
> but this and other statements were intended to make clear the
> rationale for the choice

right, that's a recurring theme of the proposed edits. I think the
result is that an implementor reading the document has a more concise
view of what she needs to do to get it right.

The document is not trying to win a debate, explain the history of every
bit, or change minds - the mailing list archive or (as you suggest) a
separate non standards track document can persist for those purposes.

I'm not opposed to a few statements of rationale here and there when
they provide useful advice to implementors, but the primary focus of a
standards track protocol specification is to provide a clear definition
of what the protocol requirements are for interoperation and quality
implementations.

In cases where a specific element can benefit from some nuance (for
instance a hypothetical "SHOULD create large fragments") then go for the
explanation, but in most cases it really just opens up a can of worms
and clarity is added by constraining the document to what is necessary.

here is an example:

"The base framing protocol is deliberately kept simple so that simple
implementations may ignore advanced features."

Hypothetically I begin my implementation of a websocket server from the
specification and I find 64 bit lengths difficult to work with. Suddenly
ambiguity sets in. Is 64 bit lengths an advanced feature? Can I ignore
it? Am I a simple implementation - what's the definition of that? If I
know I'm an advanced implementation in some other aspects does that
prohibit me from ignoring this requirement? Obviously, I figure out that
I cannot ignore it and interoperate on the web even though this text
tells me I can ignore advanced features! now the standard is internally
inconsistent. yech.

We could try and fix those problems in the text, or we can ask in what
way the goals of interoperation and quality implementations damaged by
just removing it from the specification. 

The most borderline of the cases in my mind involves removing the
rationale from "a sender MAY fragment a message". The way the text was
written created one interpretation where a sender may fragment it in
order to generate dyanmic content but it isn't clear if there is then
permission from the spec to do it for other reasons.  I think it states
the requirements more clearly if the rationale is left out, the sender
MAY do it. Period. But of course the rationale can always be reworked if
it provides useful advice and as I said this was probably the most
borderline of the ones I cited.

> or perhaps they can be kept inline in the draft with the understanding
> that they will not be present in the final version,

I would object to this approach - we have lots of issue trackers that
can track the reasons behind various decisions. Its high time to start
moving the document towards its submission state and using the document
and specific proposed changes to it as a focal point for working group
discussions.

-Patrick

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Sep 2010 17:30:04 -0400

Dave Cridland wrote:
> supported, in favour of SMTP AUTH (and preferably a dedicated submission 
> service on 587 with SASL and TLS).
> 
> The reason it's been discredited is actually because it's in a general 
> class of error referred to as "Time of check to time of use".
> 
> Dave.

Sure, hut I've long been within the email circles and I do not ever 
recall any outright conclusion.

But I do agree with your last statement.  Nonetheless, it is still an 
option in many integrated mail software and whether people have turned 
it off - don't be surprise if many have not because one of the primary 
reasons for it was that it reduced technical support cost - lesser 
need to help/setup the layman users.

ESMTP AUTH is not a required standard and RFC 4409 (only 4 years old) 
was not widely supported. But when the shift did begin with ISPs 
requiring ESMTP AUTH for their users, some immediately fell back to 
allowing IP authorization because of the huge tech support burden it 
created.  I specifically recall this exact situation with my home 
Bellsouth account when they issued a deadline notification to all 
users to begin switching to software using ESMTP AUTH.  After the 
deadline, I would say it was maybe less than a week when a 2nd 
notification indicating it was no longer a requirement and still isn't 
today - although I always had it personally setup for ESMTP AUTH.

Now of course, the ISP doesn't need to use POP4-B4-SMTP because the 
ISP user is already "IP authenticated" on their network and SMTP Relay 
is allowed.

Another subtle point regarding the SUBMISSION protocol that has it 
began to show a problem for the growing home or soho market with nats 
and 2nd, 3rd MUAs on LAN or wireless machines.

Some SMTP clients residing on a LAN or wireless machine sending mail 
will use a EHLO [IP-LITERAL] where the ip is private.  This will fail 
RFC 4409 tight EHLO validation requirement for implementations that 
will check the ip literal against the connecting IP which would be the 
NAT public IP.

I reported this issue to the Thunderbird people which now has a config 
option to set the HELLO string used.  Klensin and Gellens were also 
informed of this growing issue.  My recommendation was to add 
semantics to suggest skipping any EHLO IP-literal verification since 
AUTH was already a session requirement, not an option under PORT 587 
connections.

In any case, the point was that IP authentication *can* be a valid 
server side consideration for secondary web sockets connections.

When the HTTP session authenticates the user with HTTP/COOKIE auth, 
the binding to the IP is set and this can be used for any pending 
web-socket clients on the same IP.  Whether a TTL is required, I don't 
know if its necessary or not since IMV, there is a greater 
predictability and timeline of events with the HTTP session and WS 
session than it was with POP3 and SMTP.

Thanks

---

From: David Orchard <[email-masked]>
Date: Thu, 2 Sep 2010 14:42:07 -0700

I think the expression that versioning is an anti-pattern for the web
is in the context of human authored HTML documents, where people
notoriously view source and cut 'n paste that results in the wrong
DTDs, etc.  I don't think that a large number of people will be
cutting and pasting text containing versioning information to hybi
protocol messages, so that advice doesn't apply to hybi imo.

However, protocols that have many optional features might not do well
with single string version identifiers.  HTTP's use of version numbers
asserting the capabilities of the server rather than the features used
by the message has worked pretty well at a coarse grained level but
the different feature negotiations have had varying degrees of
success.

A lack of versioning, and I don't mean just using identifiers, is
pretty risky.  Interesting question as to whether HTTP version
identifiers have helped or not, and I tend to think they have helped.

Cheers,
Dave

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 3 Sep 2010 09:34:08 +1000

> identifiers have helped or not, and I tend to think they have helped.

HTTP servers deployed in the wild stills sees a significant proportion
of HTTP/1.0 traffic, but mostly HTTP/1.1. There is still even a few
HTTP/0.9 (== no version) requests, but those are mostly me using
telnet to get a REST resource (because I can't remember the args to
curl).

The difference in protocol behaviour between these 3 versions is
significant and it would be neigh impossible for a server to service
the variety of clients deployed without a version. Supporting 3
versions of the protocol does complicate the server, but there is no
other choice as you cannot force web clients to upgrade (nor me to
remember the args to curl)

The only time I've had real problems with different dialects of HTTP
was during the change from rfc2068 to rfc2616, both of which said they
were HTTP/1.1 (why not HTTP/1.2?        So maybe now, years later it
is great they we don't have to maintain 2068 support, but that was
only lucky as there was not wide deployment of rfc2068 clients.

cheers

---

From: James Graham <[email-masked]>
Date: Fri, 3 Sep 2010 08:47:19 +0200 (CEST)

> remember the args to curl)

So, to makw sure I understand you correctly, you are proposing that future 
clients and servers support *all* the versions of the draft that have ever 
seen non-trivial deployment (possibly including hixie-75, likely including 
hixie-76, and presumably including more future versions that happen to 
line up with significant client releases)?

---

From: John Tamplin <[email-masked]>
Date: Fri, 3 Sep 2010 02:56:50 -0400

On Fri, Sep 3, 2010 at 2:47 AM, James Graham <[email-masked]> wrote:

> hixie-76, and presumably including more future versions that happen to line
> up with significant client releases)?
>

Speaking for myself, I think we are already likely in a position of
supporting v76 for some extended period of time.  Chrome tends to get
updated pretty quickly, though certain platforms may lag getting a new
release into stable.  Unless the final spec makes FF4.0 (and I don't know
how much lead time it would take to get it in), then it is likely to exist
there for some non-trivial period of time.  I suspect at least one more
intermediate version will see some deployment so we can get real-world data.

The point is, these clients will still exist whether there is a version in
new drafts or not.  Even the question of whether you care about making them
work is orthogonal to the question of whether to put a version on them or
not.  The only thing having a version does for you is to know which version
of the protocol the other end is speaking, rather than having to guess from
the information it sent.  Unless you just send something and hope it works,
you still ultimately decide "the remote endpoint is speaking v76" in either
case -- what you do with it after that is up to you -- it could be that you
drop the connection as incompatible, or it could be you speak v76 to it.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Sep 2010 09:31:44 +0200

On 03.09.2010 08:56, John Tamplin wrote:
> ...
> The point is, these clients will still exist whether there is a version
> in new drafts or not.  Even the question of whether you care about
> making them work is orthogonal to the question of whether to put a
> version on them or not.  The only thing having a version does for you is
> to know which version of the protocol the other end is speaking, rather
> than having to guess from the information it sent.  Unless you just send
 > ...

Which might be impossible to do.

 > ...
> something and hope it works, you still ultimately decide "the remote
> endpoint is speaking v76" in either case -- what you do with it after
> that is up to you -- it could be that you drop the connection as
> incompatible, or it could be you speak v76 to it.
> ...

Yes. Sounds like a feature to me, at least before we get to 1.0.

Another benefit is that it might be easier to do comparisons between two 
draft protocols.

Best regards, Julian

---

From: Dave Cridland <[email-masked]>
Date: Fri, 03 Sep 2010 09:22:10 +0100

I'll skip the email discussion as it's not relevant here.

> server side consideration for secondary web sockets connections.
And my point is that it is not.

> web-socket clients on the same IP.  Whether a TTL is required, I  
> don't know if its necessary or not since IMV, there is a greater  

Not especially. An HTTP request may be passed through several  
proxies, a WebSocket request is less likely to.

It's important to consider that if the HTTP service provides a  
cookie, then that should be sufficient if it would be sufficient in  
HTTP. I would argue that the whole question of user authentication on  
"the web" is in dire need of a re-examination, but again, this really  
isn't the forum to do it in.

One point you made does apply here too - an IP address, if within the  
AS or local network, is sufficient to authenticate as an otherwise  
anonymous local user. This is the case used to allow SMTP relaying to  
ISP customers. I don't think this will be an option for the vast  
majrotiy of WebSocket services.

Dave.

---

From: "Simon Pieters" <[email-masked]>
Date: Fri, 03 Sep 2010 11:01:38 +0200

> want to make sure they are discussed on this list.

Ok. Here are the changes I could find since -00 and associated emails/bugs  
ignoring things that are moot with -01 and things that IIRC were discussed  
on hybi:

http://html5.org/tools/web-apps-tracker?from=4893&to=4894
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9149

http://html5.org/tools/web-apps-tracker?from=5169&to=5170
https://bugzilla.mozilla.org/show_bug.cgi?id=472529#c180 (can't find the  
relevant email)

http://html5.org/tools/web-apps-tracker?from=5174&to=5189
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027245.html

http://html5.org/tools/web-apps-tracker?from=5241&to=5244
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027673.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027674.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027675.html

http://html5.org/tools/web-apps-tracker?from=5287&to=5288
http://html5.org/tools/web-apps-tracker?from=5288&to=5289
I don't know what this was in response to.

Let me know if there's a change you'd like discussed here that's not  
listed above and I can try to dig it up.

HTH,
-- 
Simon Pieters
Opera Software

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Sep 2010 08:16:05 -0400

Good morning,

> And my point is that it is not.

Come on David, surely you are more open minded than that. :)

> An HTTP request may be passed through several proxies, 
> a WebSocket request is less likely to. 

Sure.

> One point you made does apply here too - an IP address, if within the AS 
> or local network, is sufficient to authenticate as an otherwise 

Well, David, you already made a decision on what the majority services 
will be and to (mildly) suggest there is no utility for the minority 
cases. :)

We long had a dual/multi client session framework since 1996 so my 
perspective does have a basis. WebSocket offers an alternative, 
perhaps  simplified "client/wiring" framework. For us, its more about 
single sourcing the client interface devices - again. It may also show 
to be "not ready" for prime time.

Nonetheless, while off hand the session management will naturally 
carry over which is not IP associated, IP may|could be part of it. 3rd 
party applets have leveraged "IP" in different ways, i.e. "call back 
verifiers" ideas. Overall, the reasons have been more strategic in 
some aspect, but its all about different levels of session management 
considerations.

WebSocket simply highlights these design considerations more - at 
least for us.

IMO, the majority market place, at least in the short term, will be 
more transforming existing applications including private, intranet, 
etc.  The longer term may be more public service hosting, a wider mesh 
network or some combo of decentralization/centralization server ideas.

Thanks for your input.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 03 Sep 2010 08:34:45 -0400

On Fri, 2010-09-03 at 02:56 -0400, John Tamplin wrote:

> Unless the final spec makes FF4.0 (and I don't know how much lead time
> it would take to get it in), then it is likely to exist there for some
> non-trivial period of time.  

For those that aren't aware, I'm working with the Mozilla Websockets
team. And with that hat on I can say FF is unlikely to deploy -76 in FF
4 - except perhaps under a clearly for-experiment-only namespace which
is subject to breakage at any time.

That being said, I'd love to get the specification to a state where we
could ship something based on draft-ietf-* with some confidence that at
least the basics were stable. We've got some work to do.

---

From: John Tamplin <[email-masked]>
Date: Fri, 3 Sep 2010 11:11:57 -0400

> least the basics were stable. We've got some work to do.

So FF40 final will not ship WebSockets support under the final name unless
the spec is finalized before then?  I thought 4.0b4 was running v76 and
interoperable with Chrome from the client side API?

Since most of the comments on the framing in draft 01 have been about the
wording rather than the technical details in general, I think we are pretty
close to having the framing done.  However, I expect there to be significant
changes in the handshake.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 3 Sep 2010 17:25:57 +0200

Hi Ian,

> not addressed in this draft.

FWIW, today I got another report of a user who had to modify his server
implementation of the handshake to support a reverse-proxy. He just had
to make the server respond to the headers and then read the 8-bytes key3
and emit the hash and that fixed the issue for him.

Just wanted to let you know.

Regards,
Willy

---

From: Scott Ferguson <[email-masked]>
Date: Fri, 03 Sep 2010 08:41:46 -0700

John Tamplin wrote:
> On Fri, Sep 3, 2010 at 8:34 AM, Patrick McManus <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> Since most of the comments on the framing in draft 01 have been about 
> the wording rather than the technical details in general, I think we 
> are pretty close to having the framing done.  However, I expect there 
> to be significant changes in the handshake.

I do have a minor, aesthetic suggestion for the framing to reorder the 
bits so the reserved bits are contiguous.

  * more(1)
  * length(7)
  * res(4)
  * opcode(4)

It's not a substantive or important proposal, of course, but looks a bit 
cleaner than splitting the reserved bits.

-- Scott

---

From: John Tamplin <[email-masked]>
Date: Fri, 3 Sep 2010 11:44:50 -0400

On Fri, Sep 3, 2010 at 11:41 AM, Scott Ferguson <[email-masked]> wrote:

> I do have a minor, aesthetic suggestion for the framing to reorder the bits
> so the reserved bits are contiguous.
>
>  * more(1)
>  * length(7)
>  * res(4)
>  * opcode(4)
>

I dislike having the bits of the length separated from each other (since the
16/63-bit case it will come after the opcode).  In particular, it makes it
hard to write ABNF which is clear.

---

From: Scott Ferguson <[email-masked]>
Date: Fri, 03 Sep 2010 09:15:50 -0700

John Tamplin wrote:
> On Fri, Sep 3, 2010 at 11:41 AM, Scott Ferguson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I do have a minor, aesthetic suggestion for the framing to reorder
>     the bits so the reserved bits are contiguous.
>
>      * more(1)
>      * length(7)
>      * res(4)
>      * opcode(4)
>
>     It's not a substantive or important proposal, of course, but looks
>     a bit cleaner than splitting the reserved bits.
>
>
> I dislike having the bits of the length separated from each other 
> (since the 16/63-bit case it will come after the opcode).  In 
> particular, it makes it hard to write ABNF which is clear.

There's a value in putting more and length together since they're 
related. That would help debugging because a fragment would be easily 
recognizable as %xFE or %xFF instead of varying based on the reserved 
bits as the current frame encoding requires. For short packets, having 
the high bit clear will make the length easier to scan (assuming it's a 
non-fragment) than scanning would be if the high bit varies for 
unrelated extension reasons.

   * res(4)
   * opcode(4)
   * more(1)
   * length(7)

It's a matter of taste, really. Having the reserved split in two also 
makes the frame header look more complicated because it implies that 
RES1 and RES2 are reserved for different purposes rather than just being 
generic reserved bits.

But it really doesn't matter much, so I'll just leave the point out 
there and not argue for it further.

-- Scott

---

From: John Tamplin <[email-masked]>
Date: Fri, 3 Sep 2010 12:26:10 -0400

On Fri, Sep 3, 2010 at 12:15 PM, Scott Ferguson <[email-masked]> wrote:

> It's a matter of taste, really. Having the reserved split in two also makes
> the frame header look more complicated because it implies that RES1 and RES2
> are reserved for different purposes rather than just being generic reserved
> bits.
>

Actually in the draft they are named individually (I thought it would be
easier to define future extensions rather than saying the 2nd-highest bit of
reserved1 etc), and it seems highly likely that we will want at least one
stand-alone bit for a flag in some extension.

I also don't care much, but I prefer the current formulation.

---

From: Adam Barth <[email-masked]>
Date: Fri, 3 Sep 2010 19:06:32 -0700

> significantly that versioning in protocols can be called an anti-pattern?

Versioning has been a big pain point for TLS.  Here's a presentation
that outlines some recent implementation experience:

http://www.ietf.org/proceedings/65/slides/tls-6.pdf

I encourage you to read through the presentation (it's pretty short).

> discussing a transfer protocol.

It's a continual annoyance in dealing with the IETF to have to deal
with this "browsers don't matter" attitude.  In he case of this
working group, we're working on a protocol expressly for use by
browsers, which would seem to indicate that browser implementation
experience is relevant.

> HTTP is the primary "web protocol" and AFAIK, its versioning is usually not

The version number in HTTP hasn't been change in a very long time.  I
suspect we'd encounter tremendous difficulty if we tried to change it
today.

Adam

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 06 Sep 2010 14:41:26 +0900

Hello Adam,

On 2010/09/04 11:06, Adam Barth wrote:
> On Thu, Sep 2, 2010 at 11:25 AM, Daniel Stenberg<[email-masked]>  wrote:

This is indeed discouraging. TLS server side implementers seem to be 
rather challenged. For a security-related protocol, that's rather bad 
indeed. I very much hope WS implementers can do a better job.

> with this "browsers don't matter" attitude.

Of course browsers do matter. But servers do matter, too.

> In he case of this

Of course the browser implementation experience is highly relevant! But 
that doesn't mean that necessarily the browser implementation experience 
with HTML (or TLS) is relevant to pre-RFC WS implementations.

The way I understand it, there are three things that could potentially 
be versioned:

- Handshake
- Framing
- Extensions

Of these, the handshake is versioned almost by definition (though not 
with an explicit number), given that a change of the handshake means 
different header field names (I guess there's very wide agreement that 
it would be extremely dumb to keep the same header field names with 
different semantics).

The framing is where versioning has been proposed, but it is very 
important to note that this is only for when the framing actually 
changes. As soon as the framing is 'baked', I think there's wide 
agreement that there is no need for versioning. Frankly speaking, I'd 
also prefer to have *some* kind of indication of whether the first few 
bits of a frame are a length or a frame type or what, even if that 
doesn't have to be called a version number.

For extensions, as far as I understand, there is no proposal for 
versioning in the sense that there is no plan to bundle certain 
extensions under a certain version number. (there may be some base 
protocol features (maybe multiplexing could be one of these, we don't 
know yet) that are implemented by using the extension mechanism, but 
that's a separate matter).

There is of course the possibility for each extension (as well as for 
each subprotocol) to do versioning as they please (which hopefully will 
mean as little as possible.

So overall, it seems to be that the browser experience of "be careful, 
versioning, it may not work as well as you might think" is very much heeded.

Also, versioning has been requested for framing, and in particular for 
the first few bits/bytes of framing. Squeezing information tightly into 
bytes creates a different context with respect to versioning than a 
textual protocol with lots of redundancy such as HTML.

> suspect we'd encounter tremendous difficulty if we tried to change it

Yes, indeed. The version number would only be changed if there were some 
very basic changes in the protocol. The tremendous difficulty isn't so 
much coming from a fundamental problem with versioning (if there indeed 
were some very basic protocol changes, there would probably be wide 
agreement with changing the version number) but from the fact that 
nobody currently is interested in very basic changes in the HTTP 
protocol (if you exclude this group :-).

In a similar way, it seems the big majority of contributors on this list 
agree that the version number (or the absence of a version number) 
should not change in a very, very long time *once the WS protocol, and 
in particular the framing part, is baked*.

In some ways, this reminds me of the AtomPub WG. It kept the version 
number at 0.3 while working on the spec. Everybody knew in advance that 
the final version would be version 1.0. That way, it tried to make sure 
that it had one shot at a clean spec, and reduced feature creep and 
early lock-in. I don't know how successful that were.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: David Orchard <[email-masked]>
Date: Sun, 5 Sep 2010 22:50:18 -0700

Martin, you said:

> very basic changes in the protocol. The tremendous difficulty isn't so much
> coming from a fundamental problem with versioning (if there indeed were some
> very basic protocol changes, there would probably be wide agreement with
> changing the version number) but from the fact that nobody currently is
> interested in very basic changes in the HTTP protocol (if you exclude this
> group :-).

Which is accurate, but I think that is partially because of what I
mentioned before, that the HTTP version identifier semantics weren't
defined enough.  If it was "easy" to version HTTP from 1.1 to say 1.2
with some optional components, then we may have done so.  But because
HTTP did not do anything like what I mentioned before, such as
something akin to "Minor versions are guaranteed to be compatible
changes and any unknown components may be ignored and must not cause a
fault in a receiver" or somesuch wording, than 1.1 made it very
difficult to create a version of HTTP that was forwards compatible
with existing receivers.

Cheers,
Dave

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Sep 2010 07:59:24 +0200

On Mon, Sep 06, 2010 at 02:41:26PM +0900, "Martin J. Dürst" wrote:
> >>>anti-pattern

This presentation exactly outlines what is wrong when versions are used :
to make it mandatory to support a certain feature set without full
upgradability from the previous protocol. Early adopters do not completely
implement the spec and cause the trouble. In my opinion, a version should
be used *in conjunction* with a negociation, in order to announce :
  - a behaviour on the wire (could have been useful for WS with the new
    framing)
  - the highest, fully supported standard set of feature, in order not
    to have to announce them all.

There should be no problem always announcing v1.0 with a set of 20
extensions or announcing v1.1 with a set of 2 extensions. And in turn,
the spec should not make complex extensions mandatory, or it risks
having some users not support them once a protocol upgrade requires a
version bump.

Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Sep 2010 09:17:44 +0200

> difficult to create a version of HTTP that was forwards compatible

"HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of 
the protocol. The protocol versioning policy is intended to allow the 
sender to indicate the format of a message and its capacity for 
understanding further HTTP communication, rather than the features 
obtained via that communication. No change is made to the version number 
for the addition of message components which do not affect communication 
behavior or which only add to extensible field values. The <minor> 
number is incremented when the changes made to the protocol add features 
which do not change the general message parsing algorithm, but which may 
add to the message semantics and imply additional capabilities of the 
sender. The <major> number is incremented when the format of a message 
within the protocol is changed. See RFC 2145 [36] for a fuller 
explanation." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.1>

I think another answer is that we didn't need to, because HTTP/1.1 is 
already extensible enough, thus didn't need any change to the message 
format.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 6 Sep 2010 00:36:00 -0700

On Sun, Sep 5, 2010 at 10:41 PM, "Martin J. Dürst"
<[email-masked]> wrote:
> This is indeed discouraging. TLS server side implementers seem to be rather
> challenged. For a security-related protocol, that's rather bad indeed. I
> very much hope WS implementers can do a better job.

I wish you the best of luck.  I'm not optimistic that WebSocket
servers will have a higher implementation quality than TLS servers.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Sep 2010 23:03:28 +1000

> up with significant client releases)?

James,

all I'm proposing at the moment is that we identify draft versions
while we are in draft.

However, in general, I expect that servers will need to support
multiple versions of the specification, even if they are not actually
identified with version numbers (or user-agents or heuristics or
whatever ).  That is just the reality of the situation - successful
servers must support a wide range of deployed clients and it takes
many years for clients with significant deployment to fade away
(although it is not as slow as it once was).

I would hope that we will never have the need for clients to have to
handle multiple versions.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Sep 2010 23:24:42 +1000

On 3 September 2010 06:06, John Tamplin <[email-masked]> wrote:
> On Thu, Sep 2, 2010 at 3:00 PM, Patrick McManus <[email-masked]>

>> to do, that can live outside of normative section 4.

Fragments should probably be non-zero size, else we can get silly
infinite fragmentation.

> sufficient to include an id and/or timestamp.  I would be fine with your

I'm +1 on limiting ping/pong to a single tiny frame is a good idea.

However there was a use-case of sending a large ping to determine the
mtu of a path.  I think it would be great to be able to discover mtu,
but I'm not sure that sending a big ping is a good way of doing that.
So if we go with a tiny frame ping/pong, then we need to capture the
mtu use-case elsewhere.

> it may cause other problems.

There are op-codes available to be define for large messages that are
not going to be directed at the existing text API. These should be
sufficient for future large non data messages.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Mon, 06 Sep 2010 09:51:41 -0400

> Fragments should probably be non-zero size, else we can get silly

we can add this - "The frame-more bit MUST NOT be used on any frame with
a 0 application data length." Would you like to propose that (or other)
text?

The zero-chunk on the end might be necessary if the sender didn't know
there wouldn't be more fragments when it sent the last one.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 7 Sep 2010 09:34:01 +1000

> there wouldn't be more fragments when it sent the last one.

Very good point.

> "The frame-more bit MUST NOT be used on any frame with a 0 application data length."

That is a reasonable compromise.

---

From: "Simon Pieters" <[email-masked]>
Date: Thu, 09 Sep 2010 15:21:57 +0200

On Fri, 03 Sep 2010 11:01:38 +0200, Simon Pieters <[email-masked]> wrote:

> Ok. Here are the changes I could find since -00 and associated  
> emails/bugs ignoring things that are moot with -01 and things that IIRC  
> were discussed on hybi:
>

I haven't seen any further discussion here. If there are no objections,  
could you merge in the changes (everything in  
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt&url2=http://svn.tools.ietf.org/svn/wg/hybi/websocket/draft-ietf-hybi-thewebsocketprotocol-latest  
except the framing stuff which is different in -01) in your draft?

Cheers,
-- 
Simon Pieters
Opera Software

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 9 Sep 2010 12:48:31 -0700

I am on vacation this week. Next week I will work on producing a -02 draft
based on this and other comments to the WG, barring any substantive
objections.

2010/9/9 Simon Pieters <[email-masked]>

>  On Thu, 02 Sep 2010 18:24:58 +0200, Ian Fette (イアンフェッティ) <
>>>> Is
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt&url2=http://svn.tools.ietf.org/svn/wg/hybi/websocket/draft-ietf-hybi-thewebsocketprotocol-latestexcept the framing stuff which is different in -01) in your draft?
>
>
> Cheers,
> --
> Simon Pieters
> Opera Software
>

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 14 Sep 2010 13:54:36 -0700

I did exactly the same thing for my project.  Modified Socket.IO-node to work behind haproxy.  github.com/theturtle32

Sent from my iPhone

---

From: Brian <[email-masked]>
Date: Tue, 14 Sep 2010 14:00:14 -0700

Apologies... better link:
http://github.com/Worlize/Socket.IO-node/commit/9982232032771574ceb68e2bccee4e43fd5af887

Brian

---

From: "Simon Pieters" <[email-masked]>
Date: Wed, 22 Sep 2010 23:44:09 +0200

Hi Ian,

> based on this and other comments to the WG, barring any substantive

Any progress on this?

Cheers,

>>>  Some of those changes were in response to feedback from me (mostly  
>>> sent
>>>>> to
>>>> change is, and why it was needed. I don't want to lose these changes,  
>>>> I
>>>> just
>>> emails/bugs
>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt&url2=http://svn.tools.ietf.org/svn/wg/hybi/websocket/draft-ietf-hybi-thewebsocketprotocol-latestexcept  
>> the framing stuff which is different in -01) in your draft?
>>
>>
>> Cheers,
>> --
>> Simon Pieters
>> Opera Software
>>

-- 
Simon Pieters
Opera Software

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Sep 2010 17:51:54 -0400

>> based on this and other comments to the WG, barring any substantive

Ian's chat status says that he is recovering from a minor surgery, so
he may not be online for a few days.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 22 Sep 2010 15:18:19 -0700

Apologies. I did have minor surgery on my foot Monday. Everything is fine,
but I'm taking a bit of time to recover. It's also performance management
season at Google so we're all tied down a bit with that. I am going to try
to set aside some time for this, but to be honest this week and next are a
bit rough.

-Ian

2010/9/22 John Tamplin <[email-masked]>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 23 Sep 2010 10:30:44 +0200

On Thu, 23 Sep 2010 00:18:19 +0200, Ian Fette (イアンフェッティ)  
<[email-masked]> wrote:
> Apologies. I did have minor surgery on my foot Monday. Everything is  
> fine, but I'm taking a bit of time to recover. It's also performance  
> management
> season at Google so we're all tied down a bit with that. I am going to  
> try to set aside some time for this, but to be honest this week and next  
> are a bit rough.

That sucks. :/ I certainly do not want to put blame on you but I do hope  
we all realize we missed the four-week deadline by about a month. I also  
have not seen any indication that Firefox 4 will not ship with -76 support  
(apart from that one email to this list). Apart from that, having to wait  
even longer than Firefox 4 for WebSocket to get deployed would not be nice  
either.

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

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 23 Sep 2010 08:36:34 -0700

2010/9/23 Anne van Kesteren <[email-masked]>

> On Thu, 23 Sep 2010 00:18:19 +0200, Ian Fette (イアンフェッティ) <
> That sucks. :/ I certainly do not want to put blame on you but I do hope we
> all realize we missed the four-week deadline by about a month. I also have
> not seen any indication that Firefox 4 will not ship with -76 support (apart
> from that one email to this list). Apart from that, having to wait even
> longer than Firefox 4 for WebSocket to get deployed would not be nice
> either.
>
>
Anne,

With respect, I am happy to put in some extra time to get a -02 out, but I
don't think that has been a blocking factor for e.g. Firefox or others, nor
a major contributor to us missing the 4 week deadline. A large part of our
four week deadline was devoted to some rapid changes at first, then we got
into a period where certain personalities clashed on the list for a while
and a bunch of people dropped off, and now we seem to have quieted down, but
still have a number of open issues on e.g. the handshake hanging on certain
intermediaries that have still yet to be resolved. I don't think we're quite
at the "stable" point yet, which is what I interpreted the emails from
Firefox as being desired by them to ship.

I will try to put together a -02 by the end of the week and see how far I
get, and then let's see how we can move forward. In my mind, some of the
pressing issues remaining are Issue 4 (
http://trac.tools.ietf.org/wg/hybi/trac/ticket/4), and any ideas anyone has
(including NPN, or proposing an alternate that still meets the required
properties) would be helpful.

---

From: John Tamplin <[email-masked]>
Date: Thu, 23 Sep 2010 11:47:55 -0400

On Thu, Sep 23, 2010 at 11:36 AM, Ian Fette (イアンフェッティ)
<[email-masked]> wrote:
> I will try to put together a -02 by the end of the week and see how far I get, and then let's see how we can move forward.

I can help with that if you need it as well.

> In my mind, some of the pressing issues remaining are Issue 4 (http://trac.tools.ietf.org/wg/hybi/trac/ticket/4), and any
> ideas anyone has (including NPN, or proposing an alternate that still meets the required properties) would be helpful.

I thought a couple of people posted that the simple solution of
requiring the WS server to not read the random bytes until it had
written the 101 response header solved the problem of otherwise
functional proxies causing the WS server to hang?

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Sep 2010 09:05:05 -0700

Hi Ian,
At 15:18 22-09-10, Ian wrote:
>management season at Google so we're all

I wish you a prompt recovery.  I understand that you may need some 
time before you can get back to editing the draft.

Regards,
S. Moonesamy

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 23 Sep 2010 09:53:21 -0700

> functional proxies causing the WS server to hang?

It may solve "the problem" of a particular intermediary, but I don't
think it justifies the existence of those random bytes on the wire as
not HTTP and not Websocket data.

The inclusion of those bytes was never discussed or justified.  There
is still no rigorous explanation of what benefit they provide that
could not be provided with an early ping/pong like:

   Client Handshake (with nonce)  --->
                  <---- Server handshake
                  <---- Ping (with hash of nonce)
   onOpen called
   Pong ------>

This give no extra round trip before the client onopen is called and
verifies that at least server->client websocket data can be sent.   If
client->server data cannot be sent, then the pong will not be received
and the connection will be shutdown.   Note that a ws connection can
fail at any time, so this provides no extra error handling burden on
applications as they have to handle this case anyway.

cheers

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Sep 2010 20:52:29 +0200

On Thu, Sep 23, 2010 at 09:53:21AM -0700, Greg Wilkins wrote:
> > On Thu, Sep 23, 2010 at 11:36 AM, Ian Fette (????????????????????????)
> The inclusion of those bytes was never discussed or justified.

The only valid advantage that I've seen (explained by hixie) was to
validate the ability to talk in both directions. But with the new
framing, you proposed the ping+pong which appeared a lot better to
me because not only does it validate the ability to talk, it also
validates the ability to speak the WebSocket protocol, which is
even more important.

>  There
> and the connection will be shutdown.

The connection will not necessarily be shutdown in this case. Gateways
that don't understand "upgrade" might only see a GET, and not forward
anything from the client to the server, but only a respose from the
server to the client until the server closes. And unfortunately, the
client has no way to know if its data are delivered.

I think it is reasonable to send the ping from the client first,
provided that we add "Connection: close" in order to prevent anyone
in between from considering the added data as a possible pipelined
request. 

Another thing I really like with a ping+pong opening is that it can
easily be reused and extended for non-HTTP handshakes (even raw TCP).

>   Note that a ws connection can

100% agree, and that's something that should clearly be stated in the doc.
I too often hear people say "my application *requires* HTTP keep-alive", so
we should be clear that anyone can break the connection without prior notice.

Regards,
Willy

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 24 Sep 2010 14:14:04 -0700

2010/9/3 Simon Pieters <[email-masked]>

> ignoring things that are moot with -01 and things that IIRC were discussed
Revisions below refer to revisions of
http://svn.tools.ietf.org/svn/wg/hybi/websocket/draft-ietf-hybi-thewebsocketprotocol.xml

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9149

This change as best as I can tell is already in -01

> https://bugzilla.mozilla.org/show_bug.cgi?id=472529#c180 (can't find the
Committed as r15

> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027245.html
As best as I can tell, the below corresponds to the part of the source file
that was the JavaScript API, not the protocol. This text is not present in
the HyBi document. I have not incorporated this change.
--- source (revision 5174)
+++ source (revision 5189)
@@ -80897,8 +80897,9 @@
     title="">host</var>, on port <var title="">port</var> (if one was
     specified), from <var title="">origin</var>, with the flag <var
     title="">secure</var>, with <var title="">resource name</var> as
-    the resource name, and with <var title="">protocols</var> as the
-    (possibly empty) list of protocols.</p>
+    the resource name, with <var title="">protocols</var> as the
+    (possibly empty) list of protocols, and with the <var
+    title="">defer cookies</var> flag set.</p>

Ditto with the below:
     <p class="note">If the "<span>establish a WebSocket
     connection</span>" algorithm fails, it triggers the "<span>fail
@@ -81137,10 +81138,13 @@
   <p>When the <i>WebSocket connection is established</i>, the user
   agent must <span>queue a task</span> to first change the <code
   title="dom-WebSocket-readyState">readyState</code> attribute's value
-  to <code title="dom-WebSocket-OPEN">OPEN</code> (1); then change the
-  <code title="dom-WebSocket-protocol">protocol</code> attribute's
-  value to the <span>selected WebSocket subprotocol</span>, if there
-  is one; and then <span>fire a simple event</span> named <code
+  to <code title="dom-WebSocket-OPEN">OPEN</code> (1); <span>apply the
+  cookies</span> that were collected in the <var title="">list of
+  cookies</var> when the <span title="WebSocket connection is
+  established">connection was established</span>; change the <code
+  title="dom-WebSocket-protocol">protocol</code> attribute's value to
+  the <span>selected WebSocket subprotocol</span>, if there is one;
+  and then <span>fire a simple event</span> named <code
   title="event-open">open</code> at the <code>WebSocket</code>
   object.</p>

Again, the below seems to be in the HTML/JS api, not the protocol, so I have
not incorporated any of the below.
@@ -81215,10 +81219,40 @@

   <h5>Garbage collection</h5>

-  <p>A <code>WebSocket</code> object with an open connection must not
-  be garbage collected if there are any event listeners registered for
-  <code title="event-message">message</code> events.</p>
+  <p>A <code>WebSocket</code> object whose <code
+  title="dom-WebSocket-readyState">readyState</code> attribute's value
+  was set to <code title="dom-WebSocket-CONNECTING">CONNECTING</code>
+  (0) as of the last time the <span>event loop</span> started
+  executing a <span title="concept-task">task</span> must not be
+  garbage collected if there are any event listeners registered for
+  <code title="event-open">open</code> events, <code
+  title="event-message">message</code> events, <code
+  title="event-error">error</code> events, or <code
+  title="event-close">close</code> events.</p>

+  <p>A <code>WebSocket</code> object whose <code
+  title="dom-WebSocket-readyState">readyState</code> attribute's value
+  was set to <code title="dom-WebSocket-OPEN">OPEN</code> (1) as of
+  the last time the <span>event loop</span> started executing a <span
+  title="concept-task">task</span> must not be garbage collected if
+  there are any event listeners registered for <code
+  title="event-message">message</code> events, <code
+  title="event-error">error</code> events, or <code
+  title="event-close">close</code> events.</p>
+
+  <p>A <code>WebSocket</code> object whose <code
+  title="dom-WebSocket-readyState">readyState</code> attribute's value
+  was set to <code title="dom-WebSocket-CLOSING">CLOSING</code> (2) as
+  of the last time the <span>event loop</span> started executing a
+  <span title="concept-task">task</span> must not be garbage collected
+  if there are any event listeners registered for <code
+  title="event-close">close</code> events.</p>
+
+  <p>A <code>WebSocket</code> object with <span title="WebSocket
+  connection is established">an established connection</span> that has
+  data queued to be transmitted to the network must not be garbage
+  collected.</p>
+
   <p>If a <code>WebSocket</code> object is garbage collected while its
   connection is still open, the user agent must <span>close the
   WebSocket connection</span>.</p>

Committed as r16
@@ -81540,7 +81574,7 @@

   <p>The third piece of information is given after the fields, in the
   last eight bytes of the handshake, expressed here as they would be
-  seen if interpreted as ASCII:</p>
+  seen if interpreted as UTF-8:</p>

   <pre>Tm[K T2u</pre>

Also in r16
@@ -81597,7 +81631,7 @@
   <em>set</em> cookies, as in HTTP.</p>

   <p>After the fields, the server sends the aforementioned MD5 sum, a
-  16 byte (128 bit) value, shown here as if interpreted as ASCII:</p>
+  16 byte (128 bit) value, shown here as if interpreted as UTF-8:</p>

   <pre>fQJ,fN/4F4!~K~MH</pre>

Incorporated in r17
@@ -81935,6 +81969,13 @@
   <p><i>This section only applies to user agents, not to
   servers.</i></p>

+  <p>User agents running in controlled environments, e.g. browsers on
+  mobile handsets tied to specific carriers, may offload the
+  management of the connection to another agent on the network. In
+  such a situation, the user agent for the purposes of conformance is
+  considered to include both the handset software and any such
+  agents.</p>
+
   <p class="note">This specification doesn't currently define a limit
   to the number of simultaneous connections that a client can
   establish to a server.</p>

Also in r17
@@ -81947,17 +81988,18 @@
   title="">port</var>, from an origin whose <span title="ASCII
   serialization of an origin">ASCII serialization</span> is <var
   title="">origin</var>, with a flag <var title="">secure</var>, with
-  a string giving a <var title="">resource name</var>, and with a
+  a string giving a <var title="">resource name</var>, with a
   (possibly empty) list of strings giving the <var
-  title="">protocols</var>, it must run the following steps. The <var
-  title="">host</var> must be ASCII-only (i.e. it must have been
-  punycode-encoded already if necessary). The <var
-  title="">origin</var> must not contain characters in the range
+  title="">protocols</var>, and optionally with a <var title="">defer
+  cookies</var> flag, it must run the following steps. The <var
+  title="">host</var> must have been punycode-encoded already if
+  necessary (i.e. it does not contain characters above U+007E). The
+  <var title="">origin</var> must not contain characters in the range
   U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
   LETTER Z). The <var title="">resource name</var> string must be a
-  non-empty string of ASCII characters in the range U+0021 to U+007E
-  that starts with a U+002F SOLIDUS character (/). The various strings
-  in <var title="">protocols</var> must all be non-empty strings with
+  non-empty string of characters in the range U+0021 to U+007E that
+  starts with a U+002F SOLIDUS character (/). The various strings in
+  <var title="">protocols</var> must all be non-empty strings with
   characters in the range U+0021 to U+007E, and must all be unique. <a
   href="#refsORIGIN">[ORIGIN]</a></p>

Added as r18
@@ -82194,6 +82236,16 @@
     considered a non-HTTP API for the purpose of cookie
     processing.</p>

+    <p>When one or more HTTP headers are to be added to <var
+    title="">fields</var> for this step, each header must be added
+    separately, and each header must be added as one entry consisting
+    of the header's name in its canonical case, followed by a U+003A
+    COLON character (:) and a U+0020 SPACE character, followed by the
+    value with no use of continuation lines (i.e. containing no U+000A
+    LINE FEED characters).</p>
+
+    <!-- (Cookie headers only use one header for multiple cookies.) -->
+
 <!--(v2-ws-auth)
     <div class="example">

r19
 @@ -82398,6 +82452,7 @@

    </li>

+<!--(removed since the next step is even stricter)
    <li>

     <p>If <var title="">code</var> is not three bytes long, or if any

r19
@@ -82406,6 +82461,7 @@
     these steps.</p>

    </li>
+-->

    <li>

r19
@@ -82380,8 +82432,10 @@

     <p>If <var title="">field</var> is not at least seven bytes long,
     or if the last two bytes aren't 0x0D and 0x0A respectively, or if
-    it does not contain at least two 0x20 bytes, then <span>fail the
-    WebSocket connection</span> and abort these steps.</p>
+    <var title="">field</var> contains any 0x0D bytes other than the
+    penultimate byte, or if <var title="">field</var> does not contain
+    at least two 0x20 bytes, then <span>fail the WebSocket
+    connection</span> and abort these steps.</p>

     <p>User agents may apply a timeout to this step, <spa

r20
@@ -82463,7 +82519,7 @@

     <dl class="switch">

-     <dt>If the byte is 0x0D (ASCII CR)</dt>
+     <dt>If the byte is 0x0D (UTF-8 CR)</dt>

      <dd>If the <var title="">name</var> byte array is empty, then
      jump to the <a href="#ws-ua-fields-processing">fields

r20
@@ -82471,18 +82527,18 @@
      connection</span> and abort these steps.</dd>

-     <dt>If the byte is 0x0A (ASCII LF)</dt>
+     <dt>If the byte is 0x0A (UTF-8 LF)</dt>

      <dd><span>Fail the WebSocket connection</span> and abort these
      steps.</dd>

-     <dt>If the byte is 0x3A (ASCII :)</dt>
+     <dt>If the byte is 0x3A (UTF-8 :)</dt>

      <dd>Move on to the next step.</dd>

-     <dt>If the byte is in the range 0x41 to 0x5A (ASCII A-Z)</dt>
+     <dt>If the byte is in the range 0x41 to 0x5A (UTF-8 A-Z)</dt>

      <dd>Append a byte whose value is the byte's value plus 0x20 to
      the <var title="">name</var> byte array and redo this step for

r20
@@ -82497,8 +82553,8 @@
     </dl>

     <p class="note">This reads a field name, terminated by a colon,
-    converting upper-case ASCII letters to lowercase, and aborting if
-    a stray CR or LF is found.</p>
+    converting upper-case letters in the range A-Z to lowercase, and
+    aborting if a stray CR or LF is found.</p>

    </li>

r20
@@ -82525,17 +82581,17 @@

     <dl class="switch">

-     <dt>If the byte is 0x20 (ASCII space) and <var title="">count</var>
equals 1</dt>
+     <dt>If the byte is 0x20 (UTF-8 space) and <var title="">count</var>
equals 1</dt>

      <dd>Ignore the byte and redo this step for the next byte.</dd>

-     <dt>If the byte is 0x0D (ASCII CR)</dt>
+     <dt>If the byte is 0x0D (UTF-8 CR)</dt>

      <dd>Move on to the next step.</dd>

-     <dt>If the byte is 0x0A (ASCII LF)</dt>
+     <dt>If the byte is 0x0A (UTF-8 LF)</dt>

      <dd><span>Fail the WebSocket connection</span> and abort these
      steps.</dd>

r20
@@ -82558,7 +82614,8 @@
     <p>Read a byte from the server.</p>

     <p>If the connection closes before this byte is received, or if
-    the byte is not a 0x0A byte (ASCII LF), then <span>fail the WebSocket
connection</span> and abort these steps.</p>
+    the byte is not a 0x0A byte (UTF-8 LF), then <span>fail the
+    WebSocket connection</span> and abort these steps.</p>

     <p class="note">This skips past the LF byte of the CRLF after the
     field.</p>

r20
@@ -82587,13 +82644,16 @@
     <p><i>Fields processing</i>: Read a byte from the server.</p>

     <p>If the connection closes before this byte is received, or if
-    the byte is not a 0x0A byte (ASCII LF), then <span>fail the WebSocket
connection</span> and abort these steps.</p>
+    the byte is not a 0x0A byte (UTF-8 LF), then <span>fail the
+    WebSocket connection</span> and abort these steps.</p>

     <p class="note">This skips past the LF byte of the CRLF after the
     blank line after the fields.</p>

    </li>

+   <li><p>Let the <var title="">list of cookies</var> be empty.</p></li>
+
    <li>

     <p>

r21
@@ -82629,9 +82689,9 @@
      <dt>If the entry's name is "<code
      title="http-upgrade">upgrade</code>"</dt>

-     <dd><p>If the value is not exactly equal to the string
-     "WebSocket", then <span>fail the WebSocket connection</span> and
-     abort these steps.</p></dd>
+     <dd><p>If the value, <span>converted to ASCII lowercase</span>,
+     is not exactly equal to the string "websocket", then <span>fail
+     the WebSocket connection</span> and abort these steps.</p></dd>

      <dt>If the entry's name is "<code

r21
@@ -82690,8 +82750,9 @@
      <dd>

       <p>If the relevant specification is supported by the user agent,
-      handle the cookie as defined by the appropriate specification,
-      with the resource being the one with the host <var
+      add the cookie, interpreted as defined by the appropriate
+      specification, to the <var title="">list of cookies</var>, with
+      the resource being the one with the host <var
       title="">host</var>, the port <var title="">port</var>, the path
       (and possibly query parameters) <var title="">resource
       name</var>, and the scheme <code title="">http</code> if <var

r21
@@ -82708,6 +82769,11 @@
       <p>If the relevant specification is not supported by the user
       agent, then the field must be ignored.</p>

+      <p class="note">The cookies added to the <var title="">list of
+      cookies</var> are discarded if the connection fails to be
+      established. Only if and when the connection is established do
+      the cookies actually get applied.</p>
+
      </dd>

***** This text is relating to a portion of the specification
(redirects/location: header) that is no longer in the spec *****
@@ -82764,6 +82830,9 @@
        <li><p>Close the connection if the server has not already done
        so.</p></li>

+       <li><p><span>Apply the cookies</span> in the <var title="">list
+       of cookies</var>.</p></li>
+
        <li><p>Jump back to the first step of the overall algorithm
        (the very top of the handshake).</p></li>

***** ditto -- not in the spec *****
@@ -82794,19 +82863,24 @@
      <dt>If the entry's name is "<code
      title="">www-authenticate</code>"</dt>

-     <dd><p>Obtain credentials in a manner consistent with the
-     requirements for handling the <code>WWW-Authenticate</code>
-     header in HTTP, and then close the connection (if the server has
-     not already done so) and jump back to the step labeled
-     <i>connect</i>, including the relevant authentication headers in
-     the new request.
+     <dd>
+
+      <p><span>Apply the cookies</span> in the <var title="">list of
+      cookies</var>, then obtain credentials in a manner consistent
+      with the requirements for handling the
+      <code>WWW-Authenticate</code> header in HTTP, and then close
+      the connection (if the server has not already done so) and jump
+      back to the step labeled <i>connect</i>, including the relevant
+      authentication headers in the new request.
 --><!--END complete--><!--END epub--><!--
-     <a href="#refsRFC2616">[RFC2616]</a>
+      <a href="#refsRFC2616">[RFC2616]</a>
 --><!--START complete--><!--START epub--><!--END websocket-protocol--><!--
-     <a href="#refsHTTP">[HTTP]</a>
+      <a href="#refsHTTP">[HTTP]</a>
 --><!--START websocket-protocol--><!--
-     </p></dd>
+      </p>

+     </dd>
+
      <dt>Any other name</dt>

      <dd>Ignore it.</dd>

r22
@@ -82847,7 +82921,7 @@

     <p class="example">Using the examples given earlier, this leads to
     the 16 bytes 0x30 0x73 0x74 0x33 0x52 0x6C 0x26 0x71 0x2D 0x32
-    0x5A 0x55 0x5E 0x77 0x65 0x75. In ASCII, these bytes correspond to
+    0x5A 0x55 0x5E 0x77 0x65 0x75. In UTF-8, these bytes correspond to
     the string "0st3Rl&amp;q-2ZU^weu".</p>

    </li>

r22
@@ -82871,17 +82945,58 @@

    </li>

+   <li><p>If the <var title="">defer cookies</var> flag is not set,
+   <span>apply the cookies</span> in the <var title="">list of
+   cookies</var>.</p></li>
+
    <li>

     <p>The <dfn>WebSocket connection is established</dfn>. Now the
     user agent must send and receive to and from the connection as
     described in the next section.</p>

+    <p>If the <var title="">defer cookies</var> flag is set, store the
+    <var title="">list of cookies</var> for use by the component that
+    invoked this algorithm.</p>
+
    </li>

   </ol>

+  <p>Where the algorithm above requires that a user agent <span>fail
+  the WebSocket connection</span>, the user agent may first read an
+  arbitrary number of further bytes from the connection (and then
+  discard them) before actually <span title="fail the WebSocket
+  connection">failing the WebSocket connection</span>. Similarly, if a
+  user agent can show that the bytes read from the connection so far
+  are such that there is no subsequent sequence of bytes that the
+  server can send that would not result in the user agent being
+  required to <span>fail the WebSocket connection</span>, the user
+  agent may immediately <span>fail the WebSocket connection</span>
+  without waiting for those bytes.</p>

+  <p class="note">The previous paragraph is intended to make it
+  conforming for user agents to implement the algorithm in subtlely
+  different ways that are equivalent in all ways except that they
+  terminate the connection at earlier or later points. For example, it
+  enables an implementation to buffer the entire handshake response
+  before checking it, or to verify each field as it is received rather
+  than collecting all the fields and then checking them as a
+  block.</p>
+
+  <p>When the user agent is to <dfn>apply the cookies</dfn> in a <var
+  title="">list of cookies</var>, it must handle each cookie in the
+  <var title="">list of cookies</var> as defined by the appropriate
+  specification.
+<!--END complete--><!--END epub-->
+  <a href="#refsRFC2109">[RFC2109]</a>
+  <a href="#refsRFC2965">[RFC2965]</a>
+<!--START complete--><!--START epub--><!--END websocket-protocol-->
+  <a href="#refsCOOKIES">[COOKIES]</a>
+<!--START websocket-protocol-->
+  </p>
+
+
   <h6>Data framing</h6>

   <p>Once a <span>WebSocket connection is established</span>, the user

**** dead text *****
@@ -82986,8 +83101,14 @@

         </ol>

-        <p>Otherwise, let <var title="">error</var> be true.</p>
+       </li>

+       <li>
+
+        <p>Otherwise, if the <var title="">frame type</var> is not
+        0xFF or if the <var title="">length</var> was not 0, let <var
+        title="">error</var> be true.</p>
+
        </li>

       </ol>

**** dead text *****
@@ -83096,9 +83217,10 @@

   </ol>

-  <p class="note">The closing handshake <span title="the WebSocket
-  closing handshake has finished">finishes</span> once the server
-  returns the 0xFF packet, as described above.</p>
+  <p class="note">If the user agent initiates it, the closing
+  handshake <span title="the WebSocket closing handshake has
+  finished">finishes</span> once the server returns the 0xFF frame, as
+  described above.</p>

   <hr>

r23
@@ -83125,7 +83247,25 @@

   <p><i>This section only applies to servers.</i></p>

+  <p>Servers may offload the management of the connection to other
+  agents on the network, for example load balancers and reverse
+  proxies. In such a situation, the server for the purposes of
+  conformance is considered to include all parts of the server-side
+  infrastructure from the first device to terminate the TCP connection
+  all the way to the server that processes requests and sends
+  responses.</p>

+  <div class="example">
+
+   <p>For example, a data center might have a server that responds to
+   Web Socket requests with an appropriate handshake, and then passes
+   the connection to another server to actually process the data
+   frames. For the purposes of this specification, the "server" is the
+   combination of both computers.</p>
+
+  </div>
+
+
   <h6>Reading the client's opening handshake</h6>

   <p>When a client starts a WebSocket connection, it sends its part of

r24
@@ -83355,7 +83495,10 @@
      requests to multiple hosts (e.g. in a virtual hosting
      environment), then the value should be derived from the client's
      handshake, specifically from the "<code
-     title="http-host">Host</code>" field.</dd>
+     title="http-host">Host</code>" field. The <var
+     title="">host</var> value must be lowercase (not containing
+     characters in the range U+0041 LATIN CAPITAL LETTER A to U+005A
+     LATIN CAPITAL LETTER Z).</dd>

      <dt><var title="">port</var></dt>

r25
@@ -83560,7 +83703,7 @@

     <p class="example">In the example above, this would be the 16
     bytes 0x6E 0x60 0x39 0x65 0x42 0x6B 0x39 0x7A 0x24 0x52 0x38 0x70
-    0x4F 0x74 0x56 0x62, or "n`9eBk9z$R8pOtVb" in ASCII.
+    0x4F 0x74 0x56 0x62, or "n`9eBk9z$R8pOtVb" in UTF-8.

    </li>

r25
@@ -83640,7 +83783,7 @@

    <li>

-    <p>Send two bytes 0x0D 0x0A (ASCII CRLF).</p>
+    <p>Send two bytes 0x0D 0x0A (UTF-8 CRLF).</p>

    </li>

r26
@@ -83655,9 +83798,9 @@
   <p>This completes the server's handshake. If the server finishes
   these steps without <span title="abort the WebSocket
   connection">aborting the WebSocket connection</span>, and if the
-  client does not then <span>fail the connection</span>, then the
-  connection is established and the server may begin and receiving
-  sending data, as described in the next section.</p>
+  client does not then <span>fail the WebSocket connection</span>,
+  then the connection is established and the server may begin and
+  receiving sending data, as described in the next section.</p>

 **** dead text ***
@@ -83801,7 +83944,9 @@
   <hr>

   <p>At any time, the server may decide to terminate the WebSocket
-  connection by running through the following steps:</p>
+  connection by running through the following steps. These steps
+  should be run when the <var title="">client terminated</var> flag is
+  set, if they aren't already running.</p>

   <ol>

*** irrelevant***
@@ -83903,7 +84048,6 @@
   connection</span> arbitrarily.</p>

-
   <h5>Security considerations</h5>

   <p>While this protocol is intended to be used by scripts in Web

> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027675.html
Most of this did not apply as it was all framing. I applied the following in
r27

@@ -82946,8 +82937,8 @@
    <li>

     <p>Let <var title="">key<sub>3</sub></var> be a string consisting
-    of eight random bytes (or equivalently, a random 64 bit integer
-    encoded in big-endian order).</p>
+    of eight random bytes (or equivalently, a random 64 bit unsigned
+    integer encoded in big-endian order).</p>

     <p class="example">For example, 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47
     0x58.</p>

> http://html5.org/tools/web-apps-tracker?from=5287&to=5288

I really want to add this in (NPN), but there has been enough discussion
about the state of NPN and the fact that it's not yet a recommendation that
I am leaving this out for now pending further discussion.

> I don't know what this was in response to.
ditto, pending more NPN discussion.

>
> Let me know if there's a change you'd like discussed here that's not listed
> above and I can try to dig it up.
>
> HTH,
> --
> Simon Pieters
> Opera Software
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 25 Sep 2010 11:23:52 +0200

On Thu, 23 Sep 2010 17:36:34 +0200, Ian Fette (イアンフェッティ)  
<[email-masked]> wrote:
>>> management season at Google so we're all tied down a bit with that. I  
>>> am going to try to set aside some time for this, but to be honest this  
>>> week and next are a bit rough.
>>
>> That sucks. :/ I certainly do not want to put blame on you but I do  
>> hope we all realize we missed the four-week deadline by about a month.  
>> I also have not seen any indication that Firefox 4 will not ship with  
>> -76 support (apart from that one email to this list). Apart from that,  
>> having to wait even
> With respect, I am happy to put in some extra time to get a -02 out, but  
> I don't think that has been a blocking factor for e.g. Firefox or  
> others, nor a major contributor to us missing the 4 week deadline.

To be clear, since I see now it might have misinterpreted, the "That  
sucks. :/" applied to your medical condition.

The rest was expressing a worry about the web getting stuck with -76  
because we miserably failed to put out something stable and better than  
-76 in four weeks.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sat, 25 Sep 2010 22:13:23 -0700

np :) Luckily we have -02 now, and I am sure that -03 will follow.

-Ian

2010/9/25 Anne van Kesteren <[email-masked]>

> On Thu, 23 Sep 2010 17:36:34 +0200, Ian Fette (イアンフェッティ) <
>>>> management season at Google so we're all tied down a bit with that. I am
>>>> going to try to set aside some time for this, but to be honest this week and
>>>> next are a bit rough.
>>>>
>>>
>>> even
>> a major contributor to us missing the 4 week deadline.
>>
>
> To be clear, since I see now it might have misinterpreted, the "That sucks.
> :/" applied to your medical condition.
>
> because we miserably failed to put out something stable and better than -76
> in four weeks.
>
>
>
> --
> Anne van Kesteren