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

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?

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.


> 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

Received on Friday, 5 July 2013 16:11:28 UTC