Thanks for the comments. My responses inline: On 06/07/2015 6:10 PM, "Stefan Eissing" <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 >Received on Monday, 6 July 2015 12:23:37 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:45 UTC