Re: QUIC - Our schedule and scope

["Brian Trammell (IETF)" <[e-mail]>]

hi Mark, all,

Broadly, I support Patrick's intepretation here. I'll point out that there seems to be some inconsistency between two points below:

> On 27 Oct 2017, at 08:26, Mark Nottingham <[e-mail]> wrote:
> 
> 2) V1 of QUIC should *only* address the use case of HTTP.

and

> * V1 will need to document the "invariants" of QUIC -- i.e., the parts on the wire that will not change -- to allow other use cases to be addressed by V2 and beyond.

That QUIC's handshake, pre-version-negotiation wire image, and ossification-prevention features will be "baked in" in V1 is clear, and I thought it already had been, though thanks for calling it out here.

Focusing on *only* addressing HTTP in this wire image, though, seems like it might be dangerous in ways I can't fully articulate yet... HTTP is an explicitly asymmetric protocol, with different roles for client and server well beyond the initial handshake, and as it is presently most commonly deployed, wildly different architectures for client-side and server-side implementations. Many of the things that we suspect we'll want to bring on top of QUIC in the future are less so; even Web protocols like WebSockets fit here. Will this focus lead to invariants that will make less asymmetric applications harder to build and deploy? Should we be concerned about that at this point?

Thanks, cheers,

Brian