HTTP2 Stream timeouts?

I'm wondering if we need to say something about stream timeouts in the
draft?

With HTTP/1  most servers/clients/intermediaries will timeout connections
if there is no IO activity for a period.  Some will also apply a total
timeout for a complete message to arrive.   Section
http://tools.ietf.org/html/rfc7230#section-3.4 describes how such timeouts
are handled.

With HTTP/2, the IO activity style timeout no longer applies, as there can
be lots of IO activity on other streams while a particular stream is
stalled forever.  Total timeouts can still apply.

So is section 3.4 sufficient to describe behaviour for h2?   or should we
also set some expectation as to the possible longevity (or otherwise) of
inactive streams?

Note that I can see at least one use-case for long held idle stream.
Basically it is the long polling use-case of "protocol abuse".   Frameworks
will still long poll over http2 and would benefit from a bit more certainty
over how long an idle stream can be expected to live.  I can even imaging
more creative protocol abuse where a long held stream is used to enable
push promises to be sent, thus allowing arbitrary resources to be sent from
server to client.



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.