W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 1 Apr 2014 16:25:54 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8808B24F-8361-4595-913D-CC689F697DAA@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC