HTTP-31: Error codes and Standard Action / IESG approval range

[gloinul]

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 be reserved in this registry?

[LPardue]

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.

[MikeBishop]

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

[LPardue]

WfM

[martinthomson]

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?

[LPardue]

This happened in the big error code shuffle of #2662. Folks seemed to want to avoid overlap with H2 in case of errors that might happen for a converting proxy.

[martinthomson]

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.

[LPardue]

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.

[martinthomson]

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.

[LPardue]

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?

[mnot]

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.

[MikeBishop]

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?

[martinthomson]

I think that it's fine to leave it.

[larseggert]

@gloinul do you still require changes after these explanations?

[gloinul]

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.

[larseggert]

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.

[larseggert]

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

[gloinul]

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