Re: Call for Expressions of Interest in Proposals for HTTP/2.0 and New HTTP Authentication Schemes

On Tue, Jul 3, 2012 at 5:18 AM, Jan Engelhardt <jengelh@inai.de> wrote:

>
> On Tuesday 2012-07-03 04:12, Mark Nottingham wrote:
>
> >Please submit feedback to this from your implementation or
> >deployment ASAP; without this information, I'll be forced to rely on
> >my own impressions more heavily when judging consensus (which means
> >less grounds for complaining if it doesn't go your way).
>


Mark-
A number of us are in the process of organizing for this.
4th of July week over here has added delay to this because many people are
taking the week off.

-=R

>
> >Note that one of the options on the table for the protocol, by
> >default, is to do nothing -- i.e., continue to develop HTTP/1.1
> >pipelining to address performance concerns (which quite a few
> >implementations have been doing recently).
> >
> >Likewise, no expressions of interest in implementing or using the
> >proposed authentication schemes is hard to misinterpret.
>
> Rather than reinventing extra framing atop of TCP, the use of SCTP for
> multiple concurrent HTTP streams should be considered. I wouldn't let
> "SCTP is not deployed" count as an argument. IPv6 was/is not deployed
> either (depending on who you ask). New protocols hardly ever are.
>
>
>
> Server pushes: One of the big strengths of HTTP has been that the user
> agent chooses which URLs to download data from. Other voices on the
> Internet point out that server-side pushes look like an attempt to
> counter adblockers; while adblockers will likely continue to do their
> job (after all, all data has some location), server side pushes can
> actually clog the pipe if they can send arbitrary documents anytime -
> and make it anything but spdy.
>

> Let the client choose the modus operandi. Require that a HTTP/2.x server
> supports traditional pushless operation.


>
> >> The proposals we've received are listed here:
> >>  http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals
> >>  http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals
> >>
> >> Note that a few are not fully-formed proposals in their own right,
> >>and therefore they're not really appropriate to consider as starting
> >>points for further work, but instead as input documents that can
> >>inform further discussion once we choose a starting point.
>
>