Re: Getting (Officially) Started on HTTP/2.0

On Tue, Oct 2, 2012 at 6:54 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

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

Sorry for splitting this up into a separate email, but I figure these will
end up as separate conversations.
I've also reworked the framing used in SPDY, which was not as regular as it
could be (and thus annoyed me a bit).
I'll present that here soon as well.

-=R


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