Subject: http2-encoded-data

From: Stefan Eissing <[email-masked]>
Date: Mon, 6 Jul 2015 10:06:55 +0200

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: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 6 Jul 2015 22:23:07 +1000

Thanks for the comments. My responses inline:

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

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 6 Jul 2015 14:38:37 +0000

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: [email-masked] [mailto:[email-masked]] 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

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

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

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

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 6 Jul 2015 16:52:22 +0200

> Am 06.07.2015 um 14:23 schrieb Matthew Kerwin <[email-masked]>:
> 

I think this could be worth mentioning explicitly, just to avoid misunderstandings/interop problems.

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

Sure, this would be another thing entirely. As Mike just wrote, it has been discussed already but the need has not been so great as to justify the bother. 

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

Cool.

<green/>bytes GmbH

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 10 Jul 2015 12:20:52 +1000

> misunderstandings/interop problems.
​In my editor's copy [1] I now have the following:
"Any compression or decompression context for a GZIPPED_DATA frame is
unique to that frame. An endpoint MAY interleave DATA and GZIPPED_DATA
frames on a single stream."

Will that be enough to remove any potential confusion, do you think?

Cheers

[1] http://phluid61.github.io/internet-drafts/http2-encoded-data/​

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: <[email-masked]>
Date: Fri, 10 Jul 2015 07:21:44 +0000

On Friday,10 July 2015 04:21, [email-masked] wrote:
> In my editor's copy [1] I now have the following:
> "Any compression or decompression context for a GZIPPED_DATA frame is unique to that frame. An endpoint MAY interleave DATA and GZIPPED_DATA frames on a single stream."

+1 on the change. It's a really important distinction. Perhaps you could emphasize it even more?

-keith

P.S. Missing "of": s/Significantly: the order DATA and GZIPPED_DATA frames is semantically significant/Significantly: the order of DATA and GZIPPED_DATA frames is semantically significant

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 10 Jul 2015 22:47:40 +1200

> +1 on the change. It's a really important distinction. Perhaps you could emphasize it even more?

+1 from me on the change and on the Keiths comment too.

Amos

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 10 Jul 2015 13:04:50 +0200

> Am 10.07.2015 um 12:47 schrieb Amos Jeffries <[email-masked]>:
> 

+1 The new description clarifies it for me well enough.

<green/>bytes GmbH