W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: New Version Notification for draft-nottingham-http2-encryption-02.txt

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 18 Dec 2013 10:16:40 -0800
Message-ID: <CAP+FsNfbLxJ5nLHSg-NpxyA47y0uYGkowfcOSxkUwREizYFwEw@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: Eliot Lear <lear@cisco.com>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC