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

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/
>