Subject: State of the Protocol (2014-03-31)

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Mar 2014 16:00:44 -0700

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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Apr 2014 16:25:54 +1100

Thanks for the summary, Martin; my notes below.

> have convinced many others.

My take here is that the opposition to this doesn’t seem to be strong, people just aren’t convinced it’s necessary, and want to err on the side of simplicity (understandably).

One way to resolve that would be to put BLOCKED into the implementation draft and get a bit of experience with it, to see if that makes people more enthusiastic about it; if not, we can yank it out before going final.

However, doing so requires proposed text, and soon (hint, hint).

> firmer commitment to these to proceed with this.

I don’t see this as a blocker for this implementation draft, but it’s something we need to continue to discuss.

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

Agreed. There might be other work that’s separate.

> appropriate; less so if we go with a status code.

See separate thread; I believe we have consensus to use the status code and close that issue. 

> Not a lot of feedback here.  Potentially disruptive.

… and unless we see discussion on the list very soon, it’s not going to make it into this implementation draft.

> transfer-level compression.

Possibly. The least disruptive way I can see to do it would be to allocate a flag for DATA to indicate gzip compression, along with a setting to negotiate for its use. Presumably the flag would need to be on all DATA frames in a stream, otherwise it’d be a stream error.

If we did that, however, we’d still need to discuss and document the security considerations around compressing payload without application knowledge.

> real change to protocol bits.

This is looking more and more like a separate work item. We’ll discuss once the implementation draft is out.

> be the case looking at the most recent proposals here - this shouldn't

Agreed.

> I've made some small changes in this direction, but I don't see this

This doesn’t change code, so it doesn’t block the implementation draft.

> we've agreed to address this without changing the main spec.

AIUI we haven’t agreed to address it, but we have agreed that it won’t change the main spec.

> I've made a text proposal and will consider this closed unless someone

Let’s close it.

> I've made a text proposal and will consider this closed unless someone

Likewise.

> implementations from taking unilateral action here too.)

Agreed.

> disruptive either way we call it.

Agreed.

> This is a security question primarily.  The outcome of this shouldn't

Right.

--
Mark Nottingham   http://www.mnot.net/