Re: Encouraging a healthy HTTP/2 ecosystem

On Tue, Jul 1, 2014 at 8:36 PM, James M Snell <jasnell@gmail.com> wrote:

> Alternative suggestion that would likely be much more effective:
>
> 1. Don't fast track http/2 to last call. We collectively need more
> widespread implementation experience. It's perfectly OK to let the
> implementation draft sit for a while before pushing to RFC. If those of you
> who favor the current draft as being complete and ready to go are confident
> in your positions, then surely patience won't cause a problem, right? Who
> knows, it might actually save us some trouble down the road on http/3.
>
> 2. Simplify more. Things like CONTINUATION are needless complication.
> Other bits qualify as premature optimization. Remove those bits, define a
> proper end to end extensibility model, encourage active experimentation and
> finalize later on the bits we can reasonably agree will actually work.
>
> 3. Deal with intermediaries as first class citizens in the protocol. They
> are a really that will not go away and cannot be worked around.
>

We can wait longer, or we could throw out this spec and start over, but
these arguments won't go away. Any protocol, given this group of folks will
have some number of disagreements about what features should be in or out.
 So in this case, I don't think waiting is a path to resolution.

But I don't mean to take your comment lightly.  I actually did wrack my
brain searching for empirical methods to decide "when is the protocol
ready".  Would it be a certain number of votes?  implementations?  number
of bugs?  days without incident?

Unfortunately, most of the discussions are emotional at this point -
rehashing like or dislike of the same features over and over.  In the end,
I don't see an objective way to resolve subjective classifications of
readiness - is there a good objective metric?

Mike


> - James
> On Jun 30, 2014 8:40 PM, "William Chan (陈智昌)" <willchan@chromium.org>
> wrote:
>
>> This has come up in a number of different discussions over time, and I
>> thought it'd be nice to gather a list of things that it'd be useful if
>> major implementations did in order to keep the ecosystem healthy. My
>> interest is that, before lots of other vendors start implementing HTTP/2
>> and we start getting a plethora of crappy implementations doing dumb things
>> and see actual deployment, we try to enforce good behavior so that when
>> they deploy and do stupid things, it breaks for them. I don't want HTTP/2
>> to ossify the way that TCP options have essentially become undeployable.
>> Here are some ideas for things to do:
>>
>> * In order to encourage sites to do feature detection as opposed to UA
>> sniffing, it'd be nice if major client implementations, some percentage of
>> the time, choose not to negotiate HTTP/2.
>> * In order to prevent the extension mechanism from failing (due to
>> intermediaries whitelisting extensions and disallowing all others, or some
>> other sort of brokenness), it'd be nice for clients to negotiate random
>> dummy extensions and, using out of band knowledge shared with the server,
>> require that those extensions be negotiated. More than just negotiated,
>> these extensions should probably use dummy logic like sending bogus
>> extension frames and settings. A vendor that owned both an auto-updating
>> client and popular website could enforce this.
>> * Make sure to use features that aren't necessarily required, in order to
>> make sure they remain viable. For example:
>>   - If we think servers need to at least be able to support reading
>> continuation frames (if not necessarily use them themselves), then clients
>> should make sure to exercise this code path some part of the time.
>>
>> I feel like there were a number of other things that we wanted to do, but
>> I forget. If anyone knows anything that they want early implementers to do
>> in order to keep the ecosystem healthy, I'd love to hear.
>>
>> Cheers.
>>
>>
>>