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

On Fri, Jul 5, 2013 at 11:31 AM, Michael Sweet <msweet@apple.com> wrote:

> Mike/Amos,
>
> On 2013-07-05, at 1:19 PM, Mike Belshe <mike@belshe.com> wrote:
>
> ...
>> 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.
>
>
> Something that's bugged me a little is that the context/directionality of
> the HEADERS frame type - you make certain assumptions that if you receive a
> HEADERS frame then you work with one header table and if you send a HEADERS
> frame then you work with a different table.  Whether you are receiving or
> sending request or response headers is implied by your role in a
> connection, and that is state you need to maintain and use in your
> implementation and clearly document, particularly in any generic
> client/server code that is shared between the two sides.
>
> What if instead we had two frame types: REQUEST_HEADERS and
> RESPONSE_HEADERS?  Both would carry headers like the current HEADERS frame
> type, but the type of headers would be clearly defined by the frame type
> and perhaps be easier/less error prone to understand and implement.
>

Historically, the reason we didn't go this way before is because the
framing layer has no request/response requirement by itself.  However,  I
realize HTTP is request/response (push excluded), and we're not building a
generic framing layer.

Net result:  I do agree your naming is clearer than the current 'headers'
frame, so I like that angle.  It would also make pushed streams more
self-documenting too - as receiving a response_header block makes it clear
what the push is, even though there was no formal request.


> (I don't see a need for two DATA frame types - DATA always follows headers
> and just depends on direction and the request/response type...)
>

No - this is different.  We apply compression to the headers that doesn't
make sense on the data blocks.  Whether this is differentiated by frame
type or something else, its key.

Mike





>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>