Subject: [quicwg/base-drafts] Handling of PRIORITY Frame Empty bits (#2533)

From: martinduke <[email-masked]>
Date: Wed, 20 Mar 2019 13:15:47 -0700

PR #2501 kicked up a bit more controversy than expected, so I'm opening an issue. Currently he Empty bits it the PRIORITY frame MUST be zero and MUST be ignored by the receiver.

In most other areas, we're killing connections for this kind of violation. Then again, HTTP/3 is a different protocol from QUIC.

What do people think?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533

---

From: ianswett <[email-masked]>
Date: Wed, 20 Mar 2019 13:28:07 -0700

Closing the connection SGTM.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475014794

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Mar 2019 13:42:53 -0700

I can live with must be zero and connection error if not. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475020022

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Mar 2019 20:43:11 +0000 (UTC)

Which means drop requirement to ignore them.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475020148

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 20 Mar 2019 13:47:51 -0700

I'd keep the requirement to ignore them on receipt -- why require more unnecessary checking?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475021756

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Mar 2019 13:52:47 -0700

That works, but then state that their value is completely meaningless and should not be interpreted as anything

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475023503

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 20 Mar 2019 14:01:20 -0700

@LPardue, you want to add verbiage in addition to this?

```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475026565

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Mar 2019 15:48:18 -0700

Looking back to HTTP/2, it had this to say about in-frame PADDING in DATA frames.

> Padding octets that contain no application semantic value.
      Padding octets MUST be set to zero when sending.  A receiver is
      not obligated to verify padding but MAY treat non-zero padding as
      a connection error (Section 5.4.1) of type PROTOCOL_ERROR.

https://tools.ietf.org/html/rfc7540#section-6.1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475058638

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Mar 2019 18:21:41 -0700

That is probably OK here as well.  Though the need is less acute for a 4 bit field.  Padding in DATA can be arbitrarily large.

Either way, the hope would be that at least a few implementations check and enforce.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2533#issuecomment-475085773