Subject: Reserved HTTP Frames

From: Ryan Hamilton <[email-masked]>
Date: Wed, 8 Aug 2018 14:13:18 -0700

I've a question about this text from the HTTP mapping doc:

4.2.1 <https://tools.ietf.org/html/draft-ietf-quic-http-13#section-4.2.1>.
Reserved Frame Types

   Frame types of the format "0xb + (0x1f * N)" are reserved to exercise
   the requirement that unknown types be ignored.

For what values of "N" are we talking about? I assume [0,8)? Because,
unless I'm doing the math wrong, if N can be [0,256) (and we're doing
uint8_t math) then that covers all possible values.

Cheers,

Ryan

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Aug 2018 15:51:56 +0000

No overflows.  The IANA section is more exhaustive:

Additionally, each code of the format 0xb + (0x1f * N) for values of N in the range (0..7) (that is, 0xb, 0x2a, 0x49, 0x68, 0x87, 0xa6, 0xc5, and 0xe4), the following values should be registered:

From: Ryan Hamilton <[email-masked]>
Sent: Wednesday, August 8, 2018 2:13 PM
To: IETF QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>
Subject: Reserved HTTP Frames

4.2.1<https://tools.ietf.org/html/draft-ietf-quic-http-13#section-4.2.1>.  Reserved Frame Types

For what values of "N" are we talking about? I assume [0,8)? Because, unless I'm doing the math wrong, if N can be [0,256) (and we're doing uint8_t math) then that covers all possible values.

Cheers,

Ryan

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 9 Aug 2018 17:44:39 -0700

Great, thanks! Would you be interested in a PR to add the "(0..7)" comment
to 4.2.1?

On Thu, Aug 9, 2018 at 8:51 AM, Mike Bishop <[email-masked]> wrote:

> Additionally, each code of the format 0xb + (0x1f * N) for values of N in
> the range (0..7) (that is, 0xb, 0x2a, 0x49, 0x68, 0x87, 0xa6, 0xc5, and
> 0xe4), the following values should be registered:
>
>
>
> *From:* Ryan Hamilton <[email-masked]>
> *Sent:* Wednesday, August 8, 2018 2:13 PM
> *To:* IETF QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>
> *Subject:* Reserved HTTP Frames
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Aug 2018 17:37:28 +0000

Just for some context:  As you know, the point of greasing is to create a forcing function that makes it easier to do the right thing (skip unknown values) than the wrong thing (hard-code the list of grease values and ignore those).  Given that there are only eight of them, that’s already questionable.  To the limited extent possible, I want these to be easy to generate programmatically (pick a random number, do a simple calculation with it) and require at least a little work to hard-code.

I’d really prefer not to have the specific list in the doc at all, but certainly not in the main text.  However, I don’t think clarifying that you don’t run N to infinity and truncate is a problem.

From: Ryan Hamilton <[email-masked]>
Sent: Thursday, August 9, 2018 5:45 PM
To: Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Reserved HTTP Frames

Great, thanks! Would you be interested in a PR to add the "(0..7)" comment to 4.2.1?

On Thu, Aug 9, 2018 at 8:51 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
No overflows.  The IANA section is more exhaustive:

From: Ryan Hamilton <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 8, 2018 2:13 PM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>
Subject: Reserved HTTP Frames

Cheers,

Ryan

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Aug 2018 11:05:30 -0700

On Fri, Aug 10, 2018 at 10:37 AM, Mike Bishop <[email-masked]> wrote:

> Just for some context:  As you know, the point of greasing is to create a
> forcing function that makes it easier to do the right thing (skip unknown
> values) than the wrong thing (hard-code the list of grease values and
> ignore those).  Given that there are only eight of them, that’s already
> questionable.  To the limited extent possible, I want these to be easy to
> generate programmatically (pick a random number, do a simple calculation
> with it) and require at least a *little* work to hard-code.
>

Oh, definitely agree. We want implementers to use a bit of elbow grease
here. I also share your anxiety that perhaps 8 reserved values is not quite
enough, though the particular values do at least cover every bit in the
byte.

> I’d really prefer not to have the specific list in the doc at all, but
> certainly not in the main text.  However, I don’t think clarifying that you
> don’t run N to infinity and truncate is a problem.
>

Makes sense to me.