Re: Fw: New Version Notification for draft-bishop-http2-extension-frames-01.txt

On 23 May 2014 10:24, Roberto Peon <grmocg@gmail.com> wrote:

> Extensions cannot safely modify the semantics of defined frames. This is
> implied from:
>
> Such frames are, by definition, informational and can be
>    safely ignored without affecting the shared state with the sender.
>
> Anything that does modify defined-frame semantics isn't guaranteed to
> interoperate, and is more than simply an extension.
>
>
Sorry, I should have looked at the appendices a bit better.

So, an extension can't extend DATA frames, nor replace them without going
hop-by-hop. The only end-to-end extensions we can introduce must be
informational.

Presumably this stems from the fact that we can't negotiate end-to-end
extensions. I guess a justification here is that you can use
application-level extensions instead? (I.e. new HTTP headers, etc., which
*are* end-to-end, and can be used for negotiation.)

I'd probably prefer the proposal if it just eliminated end-to-end
extensions altogether. That would harden up a lot of the wishy-washy
"ignore without error" cases, and I can't think of an end-to-end extension
(especially an informational one) that can't equally be served by a new
HTTP header*.  As a result extensions are less rich than I could have
hoped, but they're simple enough to actually potentially get implemented.


* Particularly since "An end-to-end frame on stream zero is meaningless,
and MUST be discarded upon receipt." If it's on a stream, it might as well
be in a header. The only difference is that extension frames are flow
controlled and headers (currently) aren't.


Incidentally, the compressed data frames in Appendix 3 are pretty wild; it
might be less controversial to reign them in a bit, to more closely match
what's currently in the draft (and align with the discussion that lead
thereto).


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/