Subject: [hybi] timeline

From: Justin Lee <[email-masked]>
Date: Fri, 25 Feb 2011 15:04:24 -0500

I hate to interrupt the Silvio show but I was wondering if we could get a
rundown of the remaining issues (as known today) and see what kind of
timeline we're looking at for a 1.0 of the spec.  I know it'd be speculative
but it'd help on my end if we at least had some ballpark estimates.  I can
see two issues being batted around at the moment:  the close/RST issue and
the masking frame vs payload question.  Is there anything else that needs
hashing out?

-- 
You can find me on the net at:
http://antwerkz.com
http://www.linkedin.com/in/justinlee
http://www.twitter.com/evanchooly

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 26 Feb 2011 03:24:36 +0100

>the masking frame vs payload question.  Is there anything else that needs

I would expect that at some point we'll have a draft that addresses the
many issues that have come up over the past couple of months and then we
will have some people who followed the discussions but did not comment
on individual revisions knowing they are incomplete review the draft and
fix whatever issues come up. With some luck that will happen in March.

After that we would have a Working Group Last Call review where we would
also, at the latest, invite other parties, like W3C's Web Applications
Group who work on the JavaScript API, to review the draft. When that is
done it'll likely by May, so at this point I would expect the group to
be one to two months late compared to the charter, which is remarkably
good.

Note that there are a fair share of lingering issues, for instance, in
the latest draft Ian Hickson is still listed, incorrectly, as Change
Controller for the URI schemes, I will at some point suggest once more
that implementations should not attempt to recover from UTF-8 errors,
and so on.

The crucial point, to me, is getting a draft out that pretty much fixes
"all known issues" so we get people to review it without them running
into issues like "this example hasn't been updated" so we can get issues
people have had on their minds but didn't feel like raising properly out
in the open. If we can get that by the cutoff date, that would be great.

As far as major technical issues are concerned, I think the main risk is
that we might end up re-opening the debate around the basic frame layout
with people arguing the current frame length, flag, extension encoding
needs to be simplified. If we get into that, and also fail to properly
separate "review from well-known good" and "working group last call" I'd
probably add 2 months of delay.

Also, obviously the specification we are producing is not the best place
to explain the reasoning behind important features, so we won't be able 
to respond to further criticism of, say, masking, simply by pointing out
where in the Security Considerations this is discussed, and instead ex-
change a couple of hundreds of mails telling reviewers to read the list
archives, which they won't because it is infeasible, so adding another
month to compensate for that might be wise aswell.

So, to summarize, I would expect Last Call in Q2 2011, and if we aren't
in IESG review, or past that, in Q3, something must have gone wrong more
than expected. The way to speed things up is by making sure the protocol
design is easy to understand by skimming the specification and by making
sure people review it somewhere between "early" and "when appropriate",
rather than when it's "almost too late".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Justin Lee <[email-masked]>
Date: Fri, 25 Feb 2011 21:39:11 -0500

OK.  That more or less squares with how I read Ian's statements earlier
about the -07 draft.  For what it's worth, I updated the grizzly/glassfish
implementation from -76 to -05 in just a couple of days (around some release
drama) and found the spec pretty clear.  I had to reread a couple of
sections just to clear things up but it was rather easy to update to the new
version.  For me, there is still some ambiguity about the server nonce in
the reply (is it used for anything other than just to verify its presence,
e.g.) and the ping/pong types.  I don't see anything specifying if an
implementation is required to send these with any regularity or just respond
appropriately when encountered.  I suppose requiring regular ping heartbeats
might start to consume too many network resources for larger sites but it
was just one question that popped up when implementing those frame types.

Other than that, I'm actually pretty pleased with the current state.  It was
simpler than I expected it to be from following all the discussions and
performance seems to be really high based on my admittedly simplistic
benchmark unit test.  In any case, I'll pass on what you've said to
management in hopes it will move things along on our end.  Thanks for such a
detailed response.