In reference to Mark's document: We want an identifier that describes what wire protocol is going to be spoken. This is useful whether upgrading via UPGRADE, via alt-svc, alt-protocol, etc. It seems reasonable to indicate both http with tls on tcp or http without tls on tcp. Thusfar those are the options we know are likely to happen. I could do without h2r. The client will decide what to do w.r.t. authentication anyway. If we decide we wish to have the server advertise what it'd like to see happen, then we can add that in as h2r later, and nothing old will break. @Elliot My understanding of what Jeff Pinner has been saying is that the stuff we've been doing has been quite useful in practice (today) for Twitter. -=R On Wed, Dec 18, 2013 at 7:32 AM, Michael Sweet <msweet@apple.com> wrote: > Eliot, > > On Dec 18, 2013, at 3:00 AM, Eliot Lear <lear@cisco.com> wrote: > > ... > >> I.e., we're not required to make HTTP/2 a replacement for HTTP/1 *in > the market*, as such; only to make the specs suitable for it. > > > > To answer your other question and the charter, since you went there, I > > don't really see a net benefit for most non-browser uses. We've limited > > From a resource perspective alone I think multiplexing requests over a > single connection is a major win for any HTTP-based RPC protocol (IPP, > SOAP, REST, etc.) where you expect to send or receive more than one message. > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > >
Received on Wednesday, 18 December 2013 18:17:09 UTC