http2-encoded-data

[Stefan Eissing <[e-mail]>]

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?

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.

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

Cheers,

  Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: [phone]. Amtsgericht Münster: HRB5782