- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Mon, 21 Jul 2014 12:10:56 +1000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CACweHNBEOH0cn3eQS6UxkV1=EP8YE-ZDh0cv-uR9x40t=C6kLA@mail.gmail.com>
On 21 July 2014 05:47, Mark Nottingham <mnot@mnot.net> wrote: > <https://github.com/http2/http2-spec/issues/549> > > Any further discussion? Could we address the issue that people have by > clarifying the text, perhaps? > Words would really help. I'm not sure what words to suggest, though. Maybe in ยง4.3 at the end of: "This allows a header block to be logically equivalent to a single frame." add a nota bene reference to the END_STREAM flag on HEADERS frames. Another suggestion, which is a little bit drastic, might be to remove Flags from the general Frame Format, and instead have each frame description include its own Flags field (if it needs one). My personal confusion came from the fact that an incoming DATA[END_STREAM] basically means "close for reading," so when I saw that HEADERS also has END_STREAM, occupying the same bit, with the same description, I assumed it was the same flag. Thus I overlooked the subtlety whereby HEADERS[END_STREAM] depends on END_HEADERS. If the DATA Flags and HEADERS Flags had occupied clearly different namespaces, I wouldn't have been as surprised. It would also help to explain why there's no registry for flags, even though they appear to be semi-universal (e.g. 0x4 always means END_HEADERS, 0x8 always means PADDED, etc.; 0x1 being the exception, meaning either END_STREAM or ACK) Incidentally there's an aesthetic appeal to making the generic frame header 64 bits, and we could save a byte on some of the administrative frames. -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Monday, 21 July 2014 02:11:23 UTC