W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 23 May 2014 12:04:06 +1000
Message-ID: <CACweHNAD-RnawEMCJfBTDAAsrcV9NNUDSe8LwHw-1L_27EGkag@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Friday, 23 May 2014 02:04:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC