END_STREAM flag and trailing headers

Sorry if this has previously been discussed, but my searches of spec/list
don't find it... so...

What is the reason for the multiple statements in the spec like:

  A HEADERS frame bearing an END_STREAM flag can be followed by
CONTINUATION frames.


Specifically why isn't the END_STREAM flag set iff the frame is the last
frame in that stream (in that direction)?  Why are CONTINUATION frames
allowed after the end of the stream?

As a side note that there is some confusion of the sequence of continuation
frames ends with just and END_HEADERS flag, or does it need both the
END_HEADERS and END_STREAM?  Should each of the CONTINUATION frames sent
before the final one have the END_STREAM bit set?

But back to the main question, what purpose does it serve?  Is it because
when a trailing HEADERS frame is sent, the HPACK encoding is not sure how
many frames will be needed to send the headers, so the first one is marked
with the END_STREAM and any overflows can be sent afterwards?      If so,
why not just set the end stream on the last continuation frame?

It will be clear to any HTTP receiver that the stream is about to end
because they have received a HEADERS frame after the initial headers and/or
data, so having the END_STREAM bit set provides no extra information other
than devaluing the clear meaning of the end of the stream.   Currently we
can only stop expecting more frames for a stream if ( we have seen
END_STREAM seen on a HEADERS (potentially some frames ago)  && we receive
END_HEADERS ) || (We received a DATA frame with END_STREAM) .

This is really complex and I'd like to understand why?

thanks













-- 
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.