Re: Make HTTP 2.0 message/transport format agnostic

On Sat, Mar 31, 2012 at 12:09:01PM +0200, Mark Nottingham wrote:
> 
> On 31/03/2012, at 12:06 PM, Willy Tarreau wrote:
> 
> > Hi Mark,
> > 
> > just one question to clarify one point below :
> > 
> > On Sat, Mar 31, 2012 at 11:53:08AM +0200, Mark Nottingham wrote:
> >> Some people seem to be arguing for multiple serialisations of HTTP from the
> >> start. Since the value of a standard is largely in interop and market forces,
> >> I'd strongly suggest that we not assume this until we have proven and agreed
> >> to it being necessary. 
> >> 
> >> I.e., just because SPDY (or S+M, or any other proposal) isn't good as-is
> >> right now does not automatically mean that we need two (or more)
> >> serialisations. We need to discuss our requirements and the proposals that
> >> emerge, so we can choose an appropriate path forward forward. If we end up in
> >> a corner where we can't serve all of our requirements from one, *then* we can
> >> open this box.
> > 
> > When you say "serialization", you seem to imply the on-wire format, while
> > for me (and possibly for others) serialization is what the stream looks
> > like. Right now HTTP/1.1 is serialized over multiple streaming protocols
> > (TCPv4/v6, SSL/TLS over these ones, unix sockets), with the {clear,SSL/TLS}
> > over TCP* combinations being more common than anything else and the standard
> > ones. Could you please clarify this point so that there is no ambiguity ?
> 
> I'm just contorting language to avoid using the term "binding." "On-wire
> format" is more verbose, but clear; I'll try to use it from here.

OK thanks for this precision.
(in fact in case of TCP, it's more packetization than serialization BTW).

Cheers,
Willy

Received on Saturday, 31 March 2012 10:17:01 UTC