Re: http2-encoded-data

[Matthew Kerwin <[e-mail]>]

Thanks for the comments. My responses inline:

On 06/07/2015 6:10 PM, "Stefan Eissing" <[e-mail]>
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
>