http2: what is the purpose of the "reserved" states?

[Tom Bergan <[e-mail]>]

What is the purpose of the "reserved" states? A stream transitions into a
"reserved" state after sending or receiving a PUSH_PROMISE (Section 5.1).
However, sending a PUSH_PROMISE seems equivalent in spirit to receiving
HEADERS with END_STREAM. So, why doesn't sending a PUSH_PROMISE transition
directly to "half-closed (remote)"?

AFAICT, there are only two differences between "reserved (local)" and
"half-closed (remote)":

1) A stream in "reserved (local)" cannot send DATA, but a stream in
"half-closed (remote)" can. This means a promised response must start with
HEADERS. But this seems redundant, as this requirement already exists for
all responses. See step #2 in Section 8.1.

2) Section 5.1.2 says that "Streams in either of the reserved states do not
count toward the stream limit [specified by
SETTINGS_MAX_CONCURRENT_STREAMS]." Why? Each endpoint must allocate some
state when sending or receiving a PUSH_PROMISE. It seems like the client
might as well apply its limit when receiving the PUSH_PROMISE rather than
waiting for the first HEADERS. Otherwise, the server can send an arbitrary
number of PUSH_PROMISEs without push back. This same question was asked in
the following mail, but not answered:
https://www.ietf.org/mail-archive/web/httpbisa/current/msg24452.html

Given the above, I believe a conforming implementation could merge
"reserved (local)" into "half-closed (remote)" and "reserved (remote)" into
"half-closed (local)". Does that sound right?

-Tom