PUSH_PROMISE at invalid times

In draft-05, new restriction was introduced for
PUSH_PROMISE.

'''

Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame
   causes the stream state to become indeterminate.  A receiver MUST
   treat the receipt of a PUSH_PROMISE on a stream that is neither
   "open" nor "half-closed (local)" as a connection error
   (Section 5.4.1
<http://tools.ietf.org/html/draft-ietf-httpbis-http2-05#section-5.4.1>)
of type PROTOCOL_ERROR.  Similarly, a receiver MUST
   treat the receipt of a PUSH_PROMISE that promises an illegal stream
   identifier (Section 5.1.1
<http://tools.ietf.org/html/draft-ietf-httpbis-http2-05#section-5.1.1>)
(that is, an identifier for a stream that
   is not currently in the "idle" state) as a connection error
   (Section 5.4.1
<http://tools.ietf.org/html/draft-ietf-httpbis-http2-05#section-5.4.1>)
of type PROTOCOL_ERROR.

"""


I agree that PUSH_PROMISE with illegal stream identifier or PUSH_PROMISE

after the remote endpoint sent a frame with END_STREAM are

treated as connection error of type PROTOCOL_ERROR.

But treating the other cases as connection error is problematic.
This is because the local endpoint think that stream was closed
(e.g., by sending RST_STREAM), but the remote endpoint may
not know that closure of the stream when it sent PUSH_PROMISE.
And according to the spec, the local endpoint must treat
this incoming PUSH_PROMISE as connection error, which is a
bit hard for me. This makes PUSH_PROMISE unreliable.
The alternative approach is always process PUSH_PROMISE
and its header block, thus changes stream state and compression
state. After that if the receiver thinks that it should be rejected,
then issue RST_STREAM to the promised stream ID.


Best regards,


Tatsuhiro Tsujikawa