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.