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

Thanks for the summary, Martin; my notes below.

On 1 Apr 2014, at 10:00 am, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> #362 BLOCKED frame should be added
> 
> Roberto and Hasan are passionate about this, but they don't seem to
> 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).


> #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.

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



> #424 Support for gzip at the server
> 
> I consider the odds of this happening to be low at this point.

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


> #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.

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



> #436 Enable weight of 0.
> 
> 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.


> #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.

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.


> -- 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.

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


> #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.

Agreed.


> #413 Account for Proxies
> 
> I've made some small changes in this direction, but I don't see this
> issue as actionable.

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


> #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.

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


> #421 mixed schemes
> 
> I've made a text proposal and will consider this closed unless someone
> wants to bash text.

Let’s close it.


> #423 Security implications of gzip
> 
> I've made a text proposal and will consider this closed unless someone
> wants to bash text.

Likewise.


> #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.)

Agreed.


> #443 Indicating Chosen Service
> 
> Given that this is a header field, this probably won't be too
> disruptive either way we call it.

Agreed.


> #444 Flushing Alt-Svc Cache
> 
> This is a security question primarily.  The outcome of this shouldn't
> have a visible impact.

Right.

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

Received on Tuesday, 1 April 2014 05:26:23 UTC