State of the Protocol (2014-03-31)

I plan to submit a new implementation draft as soon as I get
confirmation emails from the respective editors of HPACK and alt-svc.

Here's my highly opinionated summary of the outstanding issues.  My
focus here is on what blocks progress toward finalizing the protocol;
we have a little more flexibility when it comes to finalizing spec
text.

I've organized these into two buckets.  The first contains all the
issues where, if we decide to take action are going to cause
disruption, mostly because the wire protocol changes in some
incompatible way.

(Note: If you want to discuss a specific issue, please use or start a
thread specific to that issue.)


-- Potentially Disruptive Changes (6 issues)

These are the issues that I would have preferred to close prior to
publishing an implementation draft.

#362 BLOCKED frame should be added

Roberto and Hasan are passionate about this, but they don't seem to
have convinced many others.

#363 Recommend, forbid, or limit use of TLS renegotiation for HTTP/2

I think that we would all like to be able to to this, but it's going
to depend on providing backup mechanisms.  I've gotten positive
feedback regarding my proposals here, but I think that we'd need a
firmer commitment to these to proceed with this.

#424 Support for gzip at the server

I consider the odds of this happening to be low at this point.

#426 "Unsupported Scheme" stream error code

Partially addressed by the new Not Authoritative status code.
Potentially disruptive if we decide a stream error code is
appropriate; less so if we go with a status code.

#436 Enable weight of 0.

Not a lot of feedback here.  Potentially disruptive.

#445 Transfer-codings

We decided to remove these, but that made several people sad.  It
would be quite disruptive if we decide to re-add some sort of
transfer-level compression.


-- Less Disruptive Changes (9 issues)

These issues should not affect interoperation.  They might change
implementations in small ways, but the protocol doesn't change.

#315 HTTP:// URIs over TLS

We haven't been able to agree on what we write down here, though I'll
note that with alt-svc, this is basically a policy decision with no
real change to protocol bits.

#386 WebSockets

This is a tracking placeholder.  Unless we determine that we want to
do websockets with the same ALPN identifier - and that doesn't seem to
be the case looking at the most recent proposals here - this shouldn't
block progress.

#413 Account for Proxies

I've made some small changes in this direction, but I don't see this
issue as actionable.

#418 Refining Prior Knowledge (and #420)

This is a proposal to add DNS SRV discovery for HTTP/2.  I think that
we've agreed to address this without changing the main spec.

#421 mixed schemes

I've made a text proposal and will consider this closed unless someone
wants to bash text.

#423 Security implications of gzip

I've made a text proposal and will consider this closed unless someone
wants to bash text.

#429 HPACKing security/privacy related header fields

Not a lot of discussion here.  No protocol change if we decide to do
something, since a blacklist is basically internal.  (Nothing stopping
implementations from taking unilateral action here too.)

#443 Indicating Chosen Service

Given that this is a header field, this probably won't be too
disruptive either way we call it.

#444 Flushing Alt-Svc Cache

This is a security question primarily.  The outcome of this shouldn't
have a visible impact.

Received on Monday, 31 March 2014 23:01:11 UTC