Re: [quicwg/base-drafts] Ambiguous wording about error codes in HTTP/3 (#3276)

[Dmitri Tikhonov <[e-mail]>]

The paragraph in question (see [HTTP draft, section 8](https://tools.ietf.org/html/draft-ietf-quic-http-24#section-8)) talks about different things:

```
   Because new error codes can be defined without negotiation (see
   Section 9), receipt of an unknown error code or use of an error code
   in an unexpected context MUST NOT be treated as an error.  However,
   closing a stream can constitute an error regardless of the error code
   (see Section 4.1).
```

Let's break it up to make it easier to talk about:

1. Treating an unexpected error code as an error is not allowed, in particular:
a. Receiving unknown error is not an error in itself (a "further" error); and
b. Receiving an unexpected error code (known or unknown) is not an error.
1. A stream close may be an error independent of error code.

Item 1(a) follows from Section 9.  This does not need to be stated here.

Item 1(b) seems to suggest that error codes are not to be used to make decisions, for they could be anything, notwithstanding all the "MUST treat as error type" admonitions elsewhere in the code.  (This is what the text implies, which may not be what was intended.)

Item 2 says that some error occur due to changes in stream state and are not communicated via an error code from peer.

I would drop Items 1(a) and 1(b); Item 2 can be rephrased.

P.S. Given the loose treatment given to error codes by their recipient, it is logical to allow their sender to keep on treating specified errors as errors ("MUST treat as error..."), but allow setting the error codes to anything.  Stating that "MUST treat as error of type X and SHOULD set error code to X" sounds awkward; perhaps this guidance could be added to Section 8 as a new item.

-- 
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/3276#issuecomment-561727272