Re: Getting (Officially) Started on HTTP/2.0

On 03.10.2012 05:48, Mark Nottingham wrote:
> As you may have seen, our re-charter has been approved by the IESG.
>
> If you aren't familiar with the final text, please take a moment and
> carefully read it:
>   http://datatracker.ietf.org/wg/httpbis/charter/
>
> First and foremost, we will continue working on the revision of the
> HTTP/1.1 specification. Roy has recently finished his work on p1, and
> should finish p2 soon. As such, we'll be entering WGLC on these
> documents and prioritising any discussion on them until finished. 
> Stay
> tuned for details.
>
> Work on HTTP/2.0 will start by creating draft-ietf-httpbis-http2-00,
> based upon draft-mbelshe-httpbis-spdy-00. That draft will list Mike
> Belshe and Roberto Peon as authors, to acknowledge their 
> contribution.
>
> However, we will have a separate editorial team in charge of the
> Working Group's drafts. After extensive discussions and consultation
> with our AD, I've asked Julian Reschke, Alexey Melnikov and Martin
> Thomson to serve as editors of the HTTP/2.0 draft.
>
> Concurrently, we should start gathering issues against the draft for
> discussion; just as with the previous work, I'd like to structure as
> much of our discussion as possible around concretely identified
> issues.
>
> I'll kick that process off by nominating obvious discussion points
> like the upgrade mechanism, header compression, intermediaries, and
> server push, but of course anyone can raise a new issue, using the
> guidelines on our wiki page
> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki>.
>
> There are two things that we need to settle fairly quickly:
>
> 1. How we identify the protocol on the wire. It's likely that we're
> going to have a few different revisions of what we specify 
> implemented
> as we move along, and I want us to be crystal-clear about how that
> will be managed, so we're not stuck with interop problems down the
> road.
>
> 2. What requirements we have for negotiation of HTTP2 within TLS. As
> you should have seen, that portion of the work has been given to the
> TLS Working Group, and we need to give them some guidance about what
> we need.
>

3) The explicit session frames setup/teardown is a bit of unnecessary 
verbose state and bandwidth. Potentially adding extra RTT at times. 
There is no need for request and session setup to be different frames 
unless you want to throw away the stateless nature of HTTP. We can have 
A-to-B sessions[1] for free with per-hop request/flow ID and connection 
pinning support in the implementations. We can have client to origin 
session with negotiated headers.

Where the client assigns a connection-specific ID and the server uses 
that to construct any session ID needed at its end. This was discussed 
by the WG earlier. Similar (but not the same) as described in 
network-friendly draft. WG discussion, and development since the drafts 
were submitted has led to a some significant improvements on this over 
what network-friendly and WebSockets use, and shown that it allows for 
seamless use of HTTP/2 as stateless or stateful flows with both server- 
or client-push as optional extensions.
  eg we can write server-push as a separate (new) part-N section draft 
with the core pt1-2 HTTP/2 draft(s) containing a framing structure and 
flow control which are able to support server-push for when it is needed 
without breaking the HTTP/1 semantics requirements.

I would like to propose an updated frame layout pulling in the best 
framing details of the WebSockets, network-friendly, and speed+mobility 
proposals. This is almost ready for WG discussion, given a few more days 
to work the wording of it into the draft-mbelshe-httpbis-spdy-00 texts. 
This also proposes a few details for your (1) below.


4) I'll stick my neck out and voice it. Cross-request LZ compression 
needs to go.

The other drafts proposed a few alternative options there, per-header 
differential add/replace/remove flags.
IIRC Robert was working on something there as well?


> Following that, I suspect it'll be most useful to work on the upgrade
> mechanism (which will also help with #1 above). Patrick sent out what
> I think most people agree is a good starting point for that 
> discussion
> here: <http://www.w3.org/mid/1345470312.2877.55.camel@ds9>.
>
> We'll start these discussions soon, using the Atlanta meeting as a
> checkpoint for the work. If its' going well by then (i.e., we have a
> good set of issues and some healthy discussion, ideally with some 
> data
> starting to emerge), I'd expect us to schedule an interim meeting
> sometime early next year, to have more substantial discussion.
>
> More details to follow. Thanks to everybody for helping get us this
> far, as well as to Martin, Alexey and Julian for volunteering their
> time.
>
> Regards,
>
> --
> Mark Nottingham
> http://www.mnot.net/


AYJ

Received on Wednesday, 3 October 2012 01:55:16 UTC