SPDY is not something that Google just implemented and froze as a standard. Mozilla and others are still working on the SPDY spec in the IETF, and we're happy to see improvements. Mike Belshe continues to work on evolving the SPDY protocol even though he no longer works for Google. The latest development builds of Chrome and Firefox have just been updated to SPDY draft3.
So speaking for Google, if IETF results in changes from Speed + Mobility then Google will commit to implement it?
From what I can see the Spdy draft 3 doesn't include any improvements from Speed + Mobility so I don't see the relvance of your post. It's a shame because Speed + Mobility has real improvements (yes Microsoft does things right sometimes).
"Our plan is to continue what we've been doing: experimenting with new ideas in SPDY and recommending the good ones for standardization in IETF (http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00). In the end, we only want one protocol, so we don't intend to keep a SPDY track alive longer than a successful standards process."
Out of curiosity, what changes from Speed + Mobility would you like to see in SPDY? We'd love to hear your recommendations on spdy-dev@googlegroups.com.
What changes would I like to see? I'd like to see you work with Microsoft (and others) to improve the protocol. Microsoft with S+M has made real improvements.
Ask them. They know their stuff.
For me though, I think Microsoft held back on changes so it would be more accepted as Spdy-like. For instance the whole HTTP format seems pretty lame to me... a 16-bit string length count... amazing, iirc it's 32-bit now but who ever thought that was a good idea?!
Umm, I can't speak for Google, because I work for Mozilla. I can't speak for Mozilla's networking team either, since I'm a UI developer on the mobile team. But I feel safe saying that Mozilla is (a) committed to the standards process and (b) wants whatever final result is best for our users.
If you have questions about Mozilla's SPDY and HTTP plans, or if you want to suggest areas of work (or even contribute yourself!), you should attend the networking team meetings [1], join #networking on irc.mozilla.org, or ask on mozilla.dev.tech.network.
SPDY is in a better position to dictate the development of HTTP 2.0 as there are already two independent implementation in the wild, unlike S+M which so far only exists as a concept paper AFAIK.
That's a shame, since S+M has the potential to become the true next-gen HTTP, an improvement for everyone, while SPDY only is useful for "the elite" websites who has purchased a SSL certificate.
Most small websites with no need for SSL, unless they're hosted on a service like Tumblr or Webly, will be stuck on HTTP 1.1 "forever". It sucks that independently hosted "real" websites will have a technological disadvantage to websites hosted on third-party services unless they're willing to shell out a not insignificant amount of money ($15+ USD per year per site).
Personally, I'm glad that SPDY is providing an incentive for people to use SSL.
Also, just because SSL costs money today (it doesn't if you use startssl.com), doesn't mean it will continue to do so into the future. DANE (once the spec is finalised) will allow people to store fingerprints of their SSL certs in DNS records, signed using DNSSEC. This will remove the existing CAs from the loop.
Cool, I hadn't heard about DANE/DNSSEC. How automated will the process be?
I hope you don't have to apply/renew it manually. Buying a SSL certificate and installing it was a hassle even for me (a geek), it would have been horrible for a normal website owner.
