- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Thu, 9 Jul 2015 18:32:58 +0100
- To: Juan Benet <juan@benet.ai>
- Cc: fedor@indutny.com, ietf-http-wg@w3.org, daviddias@ipfs.io, Jeromy Johnson <why@ipfs.io>
> On 9 Jul 2015, at 17:55, Juan Benet <juan@benet.ai> wrote: > > From the above, it seems to me that the spec already defines this > (servers opening regular streams) as valid. This may be a holdover > from SPDY's clear separation between the Framing (Sec2), and the > "layering of HTTP over SPDY" (Sec3), which scopes all the HTTP- > specific rules). It does indeed seem a bit inconsistent with our > Section 8 [2]. Your analysis here is absolutely right. The HTTP/2 protocol has no limitations in its wire format or state machines that force it to be a client-server model. The vast majority of the client-server requirements really come out of Section 8, excepting a few settings and other parameters that expect there to be a client or server. > I think the separation of concerns was a useful one. Though maybe > it does not belong in the HTTP/2 spec given the traditional client- > server model -- it could very well be a negotiated extension as Cory > suggests. > > It may also be less work simply extract the HTTP/2 Framing (Section > 5) and make a symmetric framing muxer based on it. Implementation > libraries could then optionally expose the Framing part as a protocol > that layers, or not. Right now I think we should pursue the relative simplicity of a negotiated extension. We may find that it’s a bit painful to think of this as HTTP/2 in P2P mode, in which case we can revisit whether this needs to be standardised in a different way. Cory
Received on Thursday, 9 July 2015 17:33:32 UTC