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

Mike, thanks for looking over the draft. These suggestions mirror a few of
my own and seem mostly editorial.

I think the best way to address these at this point, and feel free to
disagree, is to merge streaming into master and release draft-04 for
implementation, then open these as new issues against draft-04.




On Fri, Jul 5, 2013 at 12:00 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 5 July 2013 11:48, Mike Belshe <mike@belshe.com> wrote:
> >> 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.
>
> I don't see a real advantage to this.  An endpoint knows its role.  It
> can perform a lookup: initial_headers_table[myrole].
>
> A more advanced approach might be to use a setting to describe which
> initial headers table to use.  But I think that we've concluded that
> this is better negotiated during the TLS handshake (that is, negotiate
> a new protocol).
>
> > I realize
> > HTTP is request/response (push excluded), and we're not building a
> generic
> > framing layer.
>
> Push is really request/response too :)  The request is explicit too,
> it just doesn't originate at the client.
>
>