- From: Mike Belshe <mike@belshe.com>
- Date: Mon, 16 Jul 2012 07:49:30 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABaLYCswvXipBNsjFDnmEUR2AbVow6uLe+7uLJ0RD2wY_8US_w@mail.gmail.com>
On Mon, Jul 16, 2012 at 2:16 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > In message <504E861E-C63B-466B-8E81-E6FC67DDDC7B@mnot.net>, Mark > Nottingham w > rites: > > Mark, > > The goals you point to are however goals for a WG, and I think they > are good goals for a WG, but they are not goals for a protocol. > > Goals for a protocol would sound more like: > > * "90% of all first requests fit in one packet on 1500 byte MTU" > * "request-reponse model." / "peer-to-peer model" > * "All protocol elements must be fixed size or length prefixed." > * "Must have multiplexing and pipelining" > * "Cryptographic protection is included/optional/mandatory" > * "Has (no) out-of-protection routing envelope" > * "Can (not) mix protected and unprotected requests on same connection" > * "No-extra-RT upgrade from HTTP/1 to HTTP/2" > * "Must demonstrate 10Gbit/sec load-balancer implementation on COTS PC" > * "Client must offer unique device or user identifier" > * "Not allow cookies or other server initiated tagging of client." > * "Replace User-agent with something of finite size and preferably usable." > > These are not goals. These are requirements. Goals generally have some form of user benefit to them, like "reduce latency by 25%". Your example of "90% fit in one packet" is a requirement to achieve a goal. > and so on (examples only!) > > Picking what you call "a starting point" -- no matter which of the three > you pick -- will put many of these decisions outside the reach of the WG. > > Poul-Henning > > PS: Your argument that it's better to have SPDY inside pissing out > than outside pissing in, is just capitulation by a different name. > > This is a pessimistic (and insulting) point of view. You've got it in your head that a the people that started on this work are idiots and unopen to public debate. We're not. Do you think the other companies - from Facebook to Twitter to Firefox would have ever built a protocol that they thought was a Google proprietary special? The answer is no - they want this in all browsers and they are not dummies. They wouldn't invest into SPDY if they thought it was Google only or had no chance of open collaboration. They only built it after meeting with me and others from Google and getting strong assurances that SPDY was headed for the standardization process. Anyway, I share Mark's views about the current process. It's going fine. From a practical standpoint, SPDY is the only proposal with any noteworthy adoption. But, that doesn't mean it can't change, and it doesn't mean there aren't other things that need to be done. I'm tired of hearing your anti-everything stance and direct attacks against Google and SPDY. We're here for a reason - to make something great and to get agreement on it. What are you here for? Starting with SPDY would not be "capitulation". It would be starting with the experience of at least 12 implementors from different vendors. Which other starting point offers you that? Thanks, Mike > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > >
Received on Monday, 16 July 2012 14:50:02 UTC