RE: #40 - HTTP2 default value for client supported max_concurrent_streams

There is harm borne by the unwilling client receiver: battery and data allowance are not free.

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Friday, 22 February, 2013 08:24
To: Martin Thomson
Cc: Osama Mazahir; ietf-http-wg@w3.org Group
Subject: Re: #40 - HTTP2 default value for client supported max_concurrent_streams

Yup, I understand that part. :)
I'm doing a poor job of pointing out that any harm done by doing something like this is borne by the party doing it.
... so why mandate it-- if there turns out to be a positive benefit of doing such a push in the future, fine.
I guess I'm attempting to argue that, unless we can figure out how this causes harm/is likely to be done accidentally and cause issues, then it is better to not say anything about it. Saying something about it creates a spec with is more fragile.

-=R

On Fri, Feb 22, 2013 at 8:19 AM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 22 February 2013 05:29, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
> What is the motivation for that?
I'm not suggesting that this is Osama's motivation, but look at the
Upgrade scenario: the server is the first to send on the HTTP/2.0
session with a response.  There's an obvious opportunity there to push
prior to the client SETTINGS frame arriving.  The TLS scenario is less
interesting - the client sends SETTINGS prior to any request, making
defaults non-interesting.