Subject: [quicwg/base-drafts] Clarify HTTP/2 setting parameter reservation (#3955)

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Jul 2020 08:45:13 -0700

Fixes #3954 by copying the language we already had for frame types and taking @martinthomson&#39;s suggestion from #3942.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3955

-- Commit Summary --

  * Clarify setting parameter reservation

-- File Changes --

    M draft-ietf-quic-http.md (22)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3955.patch
https://github.com/quicwg/base-drafts/pull/3955.diff

-- 
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/pull/3955

---

From: ianswett <[email-masked]>
Date: Thu, 23 Jul 2020 09:05:11 -0700

@ianswett approved this pull request.

-- 
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/pull/3955#pullrequestreview-454283881

---

From: Bence Béky <[email-masked]>
Date: Thu, 23 Jul 2020 10:49:17 -0700

@bencebeky approved this pull request.

Nice!

-- 
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/pull/3955#pullrequestreview-454363184

---

From: David Schinazi <[email-masked]>
Date: Thu, 23 Jul 2020 15:04:27 -0700

@DavidSchinazi commented on this pull request.

> @@ -1395,6 +1395,10 @@ settings to have any meaning upon receipt.
 Because the setting has no defined meaning, the value of the setting can be any
 value the implementation selects.
 
+Setting identifiers which were used in HTTP/2 where there is no corresponding
+HTTP/3 setting have also been reserved ({{iana-settings}}). These settings MUST
+NOT be sent, and receipt MAY be treated as an error of type H3_SETTINGS_ERROR.

The `MAY` here could lead to confusion down the road. Is there any reason for us to not be prescriptive here? I think it would be safer to clearly have either `MUST treat as error` or `MUST ignore` here.

-- 
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/pull/3955#pullrequestreview-454526804

---

From: David Schinazi <[email-masked]>
Date: Thu, 23 Jul 2020 15:06:28 -0700

> @@ -2316,20 +2320,26 @@ SETTINGS_HEADER_TABLE_SIZE:
 
 SETTINGS_ENABLE_PUSH:
 : This is removed in favor of the MAX_PUSH_ID which provides a more granular
-  control over server push.
+  control over server push.  Specifying a setting with the identifier 0x2

Could we instead phrase these as normative? For example: `Endpoints MUST NOT send a setting with identifier 0x2 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame.`

-- 
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/pull/3955#pullrequestreview-454527789

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jul 2020 16:29:03 -0700

@martinthomson approved this pull request.

...with or without David's changes.

-- 
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/pull/3955#pullrequestreview-454560173

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Jul 2020 11:39:04 -0700

@MikeBishop commented on this pull request.

We've used MUST NOT send / MAY error elsewhere when we haven't wanted to mandate checking.  It's enough of a deterrent to the bad behavior, when the requirement to treat as an error isn't vital to interop.  That said, it also isn't difficult to do the check, so if there's consensus to require it, I'm not opposed to the suggestion.

-- 
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/pull/3955#discussion_r460224632

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Jul 2020 11:41:02 -0700

SETTINGS_ENABLE_PUSH:

Nothing in this appendix is normative, by design.  The normative requirement is in the body of the document, and this appendix simply notes that there is a prohibition.  I could add a reference to the prohibition, if that would help.

-- 
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/pull/3955#discussion_r460225544

---

From: David Schinazi <[email-masked]>
Date: Fri, 24 Jul 2020 11:58:47 -0700

SETTINGS_ENABLE_PUSH:

A reference to the prohibition works for me, I just want to make sure we have text somewhere clearly stating that endpoints MUST NOT send those

-- 
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/pull/3955#discussion_r460233601

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 24 Jul 2020 14:53:37 -0700

@janaiyengar commented on this pull request.

```suggestion
NOT be sent, and their receipt MAY be treated as an error of type H3_SETTINGS_ERROR.
```

I would be in favor of `MUST treat as error`. This isn't hard to detect, and it seems quite reasonable to close the connection on such errors.

-- 
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/pull/3955#pullrequestreview-454585794

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Jul 2020 11:40:20 -0700

@LPardue points out that SETTINGS and frames are different, because of tunneling intermediaries.  The intermediary need not check every received frame for validity if they're not processing the frames.  SETTINGS, on the other hand, have to be checked because they're inherently hop-by-hop.  While I'm not crazy about having SETTINGS and frames be different, there is at least a justification for it.

-- 
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/pull/3955#issuecomment-665209707

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Jul 2020 20:31:56 -0700

I'm sorry @MikeBishop, that makes no sense.  You can't pick and choose which parts of a protocol you understand.

-- 
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/pull/3955#issuecomment-665410326

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 05:48:09 -0700

@MikeBishop : Doesn't that argument then argue for MUST close the connection on error? What am I missing?

-- 
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/pull/3955#issuecomment-666343257