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

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

I've discussed some of this before. One case involves more efficient
handling of multipart data as an alternative to MIME; another deals with
inserting incremental checksums into a long lived stream. I am also
exploring whether or not it will be possible to implement things like mqtt
efficiently and visibly as a sub protocol of http2 framing without being
forced to push it all into opaque data frames. I'm quite certain that these
cases aren't interesting to everyone, nor are they critical to the core of
http2, a good end to end extensibility model makes it possible for me to
experiment independently without having to worry so much about the
capabilities of the intermediary infrastructure.
On May 23, 2014 2:15 AM, "Matthew Kerwin" <[e-mail]> wrote:

>
> On 23 May 2014 15:26, Mike Bishop <[e-mail]> wrote:
>
>>  My intermediate version said all extensions were hop-by-hop and
>> negotiated; end-to-end was added in response to James’ feedback.  The
>> requirement that extensions define how, if at all, they get translated to
>> back-end links that do/do not support the extension was the only end-to-end
>> version I had prior to that change.  I’m still ambivalent about that, but
>> if there’s a use-case, I’m not opposed.
>>
>>
> ​I'd be interested to know what James's extensions are.
> ​
>
>
>>  If we do allow end-to-end, though, I think they *have* to be silently
>> discardable -- because, as Matthew observes, there’s no chance to
>> negotiate.  If I can’t know what you’ll recognize, I can’t avoid sending
>> you something you won’t.
>>
>>
> ​Yeah, I agree, if they are allowed.​
>
>
>
>>  The only end-to-end extension I’ve currently thought of is the one that
>> was a sample in the previous version, Server Hint.  (Forget if that’s what
>> we actually called it.)  Basically, rather than actively pushing, it’s a
>> server-driven “You’ll want to check that these resources are in your cache
>> and current.” that works for when you suspect a client may already have a
>> resource, or the resource is hosted on another server.  There’s no harm if
>> an intermediary observes it going by and also freshens its cache, but the
>> intended recipient is the user agent.  But like Push, if the UA just drops
>> it, it will discover that it wants the resource a little later.
>>
>>
> ​Sounds to me like a HTTP header. In fact, it sounds like something in the
> Cache-Control family. Just because HTTP/2 does server push doesn't mean
> sending unsolicited information (call it hints, whatever) is limited ​to
> HTTP/2. HTTP/1.1 could definitely benefit from such an extension, if it was
> supported.
>
>
>
>>  As for hardening, Gabriel and I discussed that some.  Let’s say we’re
>> just talking about hop-by-hop:
>>
>>    - If we say you can’t send *any* extension frames until you’ve seen
>>    the other party’s EXTENSIONS, then you can’t use any in your first
>>    request.  That may be acceptable, but seems sub-optimal.
>>
>>
> ​​Could you move the EXTENSIONS frame to a settings parameter? A single
> settings frame could contain multiple such parameters, and settings are
> already mandatorily sent as soon as the connection is established, and
> they're acked.​
>
>
>>    - If we say you MUST NOT send even informative extensions once you’ve
>>    seen the other party’s EXTENSIONS and you know they haven’t requested it,
>>    how do you know when to
>>    ​
>>    ​
>>    enforce the MUST NOT?
>>
>>
> ​Start at time 0. I don't see why it should be a problem for an extension
> frame that may have caused a protocol error earlier to suddenly become
> legal.​
>
>
> Now we need an ACK for this too, or every connection begins ​with
>> SETTINGS-EXTENSIONS-PING to simulate one.  Plus, that means the server has
>> to maintain two different states -- one in which it permits unknown frames,
>> and one in which it doesn’t.
>>
>>
> Another reason to use a setting?
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>