Subject: [quicwg/base-drafts] HTTP-31: Error codes and Standard Action / IESG approval range (#4231)

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2020 07:54:12 -0700

Section 11.2.3: https://www.ietf.org/archive/id/draft-ietf-quic-http-31.html#name-error-codes

A question as this registry has defined error codes starting at 0x0100 which is outside of the Standards Action / IESG approval range, there are no concerns that it will be specification required to add new code points directly adjecent to these being registered? 

Secondly, based on what being done in other registries should the [HTTP/2 error codes](https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml#error-code) be reserved in this registry? 

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

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Oct 2020 08:01:32 -0700

Thanks. I think this arises from the error code reshuffling.

I'm not so worried about adjacency so long as new error HTTP/3 codes don't conflict with HTTP/2 error codes (which was the point of shifting the range). So resevering the HTTP/2 codes seems sensible to me.

-- 
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/4231#issuecomment-710100000

---

From: Mike Bishop <[email-masked]>
Date: Fri, 16 Oct 2020 12:35:01 -0700

Yes, we should reserve the HTTP/2 error codes.  However, the original intent was that the error codes assigned by the document be within the Standards Action space.  Perhaps it would be cleaner to say:
- 0x00 to 0x3f:  Reserved
- 0x40 to 0x7ff:  Standards Action
- 0x800+:  Specification Required

-- 
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/4231#issuecomment-710487912

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Oct 2020 12:36:24 -0700

WfM

-- 
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/4231#issuecomment-710490039

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Oct 2020 16:32:57 -0700

OK, I completely missed some developments here.  Why are we using the 2 byte space for error codes?  We can't we start at 0, match the HTTP/2 values, and reserve those that don't map properly?

-- 
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/4231#issuecomment-711440555

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 18 Oct 2020 17:01:06 -0700

This happened in the big error code shuffle of https://github.com/quicwg/base-drafts/pull/2662. Folks seemed to want to avoid overlap with H2 in case of errors that _might_ happen for a converting proxy.

-- 
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/4231#issuecomment-711443826

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Oct 2020 17:05:57 -0700

I see the request there was to avoid overlap.

That was prior to moving to using varints.  I think that having these in the 0x00-0x3f space would be worth doing, if only so that the registration policies are consistent.  The shift by 0x100 was excessive.  0x20 would have been plenty.

-- 
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/4231#issuecomment-711444640

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 18 Oct 2020 17:12:48 -0700

The H3 error codes always squatted in the 0x100 space (HTTP_MALFORMED_FRAME...), so I think there's always been a problem. Having consistent policies is sensible, but moving the error codes again is going to be slightly painful.

-- 
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/4231#issuecomment-711445800

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Oct 2020 17:18:30 -0700

If you don't want to renumber (which is entirely reasonable), then these error codes are just taken from the specification required space.  I don't see any real problem with that.

-- 
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/4231#issuecomment-711446787

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 18 Oct 2020 17:34:07 -0700

I'm no expert in the area of registration. If some short term pain makes it easier in the long term then that seems reasonable. Ultimately the HTTP WG is going to be taking care of HTTP/3 in future, does @mnot have an opinion?

-- 
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/4231#issuecomment-711449770

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 18 Oct 2020 17:38:23 -0700

No strong opinion, but given that the primary use case for these is debugging http stacks, not exposure to applications, on the face of it I don't think alignment is worth the last-minute pain.

-- 
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/4231#issuecomment-711450439

---

From: Mike Bishop <[email-masked]>
Date: Sun, 18 Oct 2020 19:48:53 -0700

So it sounds like our options on the table are:
1. **Leave it.**  It's *weird*, but not *wrong*.
2. **Renumber**, which is going to make implementers sad.
3. **Rejigger** the boundaries of how things are registered.

(2) is right out, I think.  Any arguments for (3), or do we just grit our teeth and walk around the odd lump in the spec from now on?

-- 
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/4231#issuecomment-711480240

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Oct 2020 20:13:40 -0700

I think that it's fine to leave 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/issues/4231#issuecomment-711486634

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Oct 2020 04:14:21 -0700

@gloinul do you still require changes after these explanations?

-- 
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/4231#issuecomment-712075294

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Oct 2020 07:36:59 -0700

I don't require any change here. I was noting the inconsistency in the registration policy. I think leaving things are acceptable. What I think might be worth it is to note the intention to avoid registrations overlapping with HTTP/2. That is simply to ensure that IETF + IESG knows what to consider in future registrations. 

-- 
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/4231#issuecomment-712208101

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Oct 2020 11:00:47 -0700

OK, if any of the editors feels like adding a PR on this, please do so. Otherwise, we can close this when we are publishing the next revisions.

-- 
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/4231#issuecomment-712342393

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Oct 2020 11:03:21 -0700

(In any event, it will be "editorial".)

-- 
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/4231#issuecomment-712345887

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Oct 2020 01:57:17 -0700

So I think #4251 resolves the last aspects of this issue by providing basic guidance. 

-- 
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/4231#issuecomment-712701530

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Oct 2020 07:26:51 -0700

Closed #4231 via #4251.

-- 
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/4231#event-3899048876