RE: http2-encoded-data

When we were discussing extensions, the draft I originally proposed allocated a frame type to the transmission of frames with larger frame numbers and designated a portion of the (larger) frame space as experimental.  As part of the integration of the various extension methods with themselves and the core spec, it was pointed out that this could itself be an extension adopted by the WG if we started running short of frame types.  Since there aren’t many extensions yet, and not all of them define new frames, we haven’t needed to go there so far.  Using a string identifier might also be an option when we go to define that frame.

From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
Sent: Monday, July 6, 2015 5:23 AM
To: Stefan Eissing
Cc: HTTP Working Group
Subject: Re: http2-encoded-data


Thanks for the comments. My responses inline:

On 06/07/2015 6:10 PM, "Stefan Eissing" <stefan.eissing@greenbytes.de<mailto:stefan.eissing@greenbytes.de>> wrote:
>
> My comments re http://tools.ietf.org/html/draft-kerwin-http2-encoded-data-05:

>
> Should a client announcing support be prepared to receive DATA *and* GZIPPED_DATA frames for a single stream? There are two scenarios where I could see that happen:
> 1. The ACCEPT_GZIPPED_DATA is received while a stream's DATA is ongoing and the endpoint might want to switch
> 2. On a gzipped stream, small data chunks might arise that are not worth zipping. Can a server send them as DATA?
>

Yep, that's perfectly (and intentionally) acceptable. If it's not clear enough, I could add some words.

>
> More on the meta h2 level:
> - Allocating numbers from a small pool like frame types and error codes gets difficult when several parties are considering extending a protocol. Before safe numbers are allocated, experimental implementations need to exist which may later clash. String identifiers seem to have worked better in the past.
>
> A possible solution to this could be an X-FRAME that carries an identifier string in its payload. A playground until business gets serious and numbers are allocated in the protocol.
>

If you look at earlier versions, I originally made it a general 'encoded data' frame, with a registry of codings and TE-type negotiations. That would have reduced pressure on the frame type registry space when introducing other encodings. (If that happened.)

I dropped it back to just gzip because it seemed like that would cover 90% of what people would want from it, while being a whole lot simpler.

If an X-FRAME spec/draft existed I wouldn't be opposed to using it, but it doesn't, and I personally don't see enough need to warrant writing one myself.

>
> - Sometimes, extensions depend on each other. For an endpoint, it is much easier/safer/robust to receive and process extension capabilities in a package (i.e. single frame). Example: TLS extensions like SNI and ALPN have practical dependencies, as for servers protocol support may be configured per server. The answer to ALPN depends on the SNI. Receiving SNI+ALPN in one protocol "packet" makes processing more robust.
>

Indeed, the -05 revision was transitional; in -06 it uses a setting. <http://tools.ietf.org/html/draft-kerwin-http2-encoded-data-06>

>
> Cheers,
>
>   Stefan
>