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

[James M Snell <[e-mail]>]

I have two real world use cases for extension end to end frames that cannot
be served by new http headers. Using headers to negotiate their use works
perfectly well. So I'd be -1 on removing that aspect.
On May 22, 2014 7:08 PM, "Matthew Kerwin" <[e-mail]> wrote:

> On 23 May 2014 10:24, Roberto Peon <[e-mail]> 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/
>