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