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

The EoI wiki at http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI says that the deadline is "no later than 15 July 2012", so there still are a few days, right?

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Tuesday, 3 July, 2012 12:14
To: Jan Engelhardt
Cc: Mark Nottingham; HTTP Working Group
Subject: 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<mailto: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.