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: James M Snell <jasnell@gmail.com>
Date: Thu, 22 May 2014 20:18:32 -0700
Message-ID: <CABP7RbddCc=M69BrXSNz7p9pr-07RNs8+y8tvvubjTLLnUXgBA@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, ietf-http-wg@w3.org, Roberto Peon <grmocg@gmail.com>
I will say, however, that I'd prefer that unknown end to end extensions at
the endpoints result in hard exceptions rather than must ignore.
On May 22, 2014 7:08 PM, "Matthew Kerwin" <matthew@kerwin.net.au> wrote:

> 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 03:19:00 UTC

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