Re: Misc Comments on Layering layering work and sections 1-5.

On Fri, Jul 5, 2013 at 9:10 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 6/07/2013 3:37 a.m., Mike Belshe wrote:
>
>> Here are a bunch of comments on the latest spec.  Some of these are
>> really minor.  Let me know the best way to provide this feedback.
>>
>> 2 high-level bits about the layering:
>>
>> a)  State diagram for streams.
>> This is a good diagram.  Suggestion:  Remove the "idle" state.  The
>> diagram (and text) states that all states that could ever exist are "idle",
>> which seems like they exist somehow.  So instead of starting in idle, why
>> not just depict 4 entry points into the state machine?
>>    a) PP send -> takes you to reserved (local)
>>    b) PP receive -> takes you to reserved (remote)
>>    c) H send -> takes you to open
>>    d) H receive -> takes you to open
>>
>> b) Now that we're getting the stream lifecycle clean again, it will soon
>> be a good time to rethink the naming.  When you're new to the protocol, its
>> not clear that "HEADERS" is a way to start a stream.  START_STREAM would be
>> cleaner.  Similarly, PUSH_PROMISE requires a lot of knowledge and doesn't
>> sound stream-ish.  PROMISE_STREAM would be better.
>>
>> Sorry to bring up naming - but I do think this is extremely important for
>> making the protocol easy to understand when folks read it for the first
>> time.
>>
>
> Since this is being built as an upgrade on HTTP/1 and many implementers
> will have an HTTP/1 terminology background it would seem easier to use that
> terminology for these things. The suggested "START_STREAM" was once called
> "request headers" or "reply headers" depending on direction. It is now
> combined into one frame type for both directions so perhapse dropping the
> initial word and just calling it a HEADERS will be more familiar to
> implementers, yes?
>

I'm looking for a name that indicates "beginning" or "start".  HTTP/1
doesn't have framing, of course, but does offer "Section 5. Request".  It's
a logical start point -- make a request.




>
> PUSH_PROMISE is a new term without equivalence and all the talk so far has
> been about it under that name - so why change? particularly if that new
> scary "STREAM" word is halted at the doorway from SPDY world.


I don't understand - the HTTP/2 spec uses "stream" pervasively.  It's not a
spdy remnant - its a practicality of HTTP/2.

Both PUSH_PROMISE and HEADERS are mechanisms to start streams, the core of
HTTP2.  The reason for change is because we often talk about "on stream"
concepts, and

Mike





>
>
>
>  5.1
>> * We might reword the way we introduce the concept of 'associated stream'
>> here.
>>   Example
>>     "Sending a PUSH_PROMISE frame marks the associated stream..." .
>>   Perhaps change to:
>>    "Sending a PP frame creates a stream promised for future use.
>>  Promised streams ar always associated with an existing, open stream."
>>
>> Editorial:  it saddens me that so much specification complexity is added
>> to the protocol for push when push is so secondary to the core protocol.
>>
>
> Ditto. Can PUSH be cleanly separated from the core protocol and made a
> second document?
>
> Amos
>
>