Original text:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error.  In HTTP/2 the </del>  error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type <del> H3_FRAME_ERROR. </del>  A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see h2-update-

Reviewer comments:
This lets servers be more permissive if they want to treat it like the Header but allows them to be strict if they want. Since this is not an error in the frame itself, change the code to a general error; reason phrase is available if people feel it important to share.
In . NAME highlighted our treatment of structured fields parsing failures for the Priority header was a bit naff. We should just defer to structured fields, and that's what PR does. It struck me that our requirement for similar failures while processing PRIORITYUPDATE frames seems a bit overzealous in light of . From URL We introduced the current text as part of addressing . I think perhaps I misread the comment at URL There's a difference between a badly formed HTTP/2 or HTTP/3 frame (imagine one that is shorter than it claims to be, that's already described by those documents), and a frame that contains contents some other specification deems invalid. It now seems to me like it would be ok to defer to structured fields rules here. This would manifest as the receiver having processed the frame, but ignoring the value altogether (and treating it like an omission, which we explain how to deal with elsewhere). Thoughts?
While I do not have a strong opinion, I'm not sure if we need to revisit our previous decision. FWIW, IIUC, this is choosing between two principles: Frames are hop-by-hop signal, therefore the connection should be closed when receiving a malformed signal. Syntax of the value of the PRIORITY_UPDATE frame is the same as that of the header field and therefore malformed values should be ignored.
In the quiche library H3 layer, we handle all of the frame handling recommendations inside the library. When we process received HEADERS frames, we enure frame and QPACK requirements are satisfied and that we can construct a field section but defer all processing of the field section to applications. We don't process PRIORITY_UPDATE frames yet but if we did, we would likely pass the Structured Field Dictionary up to the application to deal with. With the current text we would either need to embed structured fields parsing into the h3 library code, or make the application responsible for adhering to the requirements. Both of hose deviate from our general implementation design (that's not an excuse, we'll have to do what the WG consensus tells us to do). My thinking is that the contents of a frame's Priority Field Value is not a property of an HTTP/2 or HTTP/3 connection. If the Dictionary cannot be parsed, it does not indicate a problem with the connection. It indicates a malformed Dictionary and there are procedures defined on how to handle that in Structured Fields. Since we allow for omission of parameters in this frame, it doesn't seem that different for receivers to parse a Dictionary, fail it and treat it like omission.
Thank you for elaborating. Reading your argument, I'd be supportive to relaxing the current requirement (MUST). Maybe changing MUST to MAY or SHOULD would be the most desirable outcome, as I believe there's no reason to prohibit endpoints from employing a validity check against hop-by-hop signals.
I see you point, thanks. I think this is a case for , I can make a PR for that. I don't think that is the correct code though. URL says: requirements or with an invalid size was received. And IIUC what you want is to communicate that a problem occured at a different layer of abstraction. I think is ok unless you think we need to define a new error code just for this.
From purely editorial perspective, I'm not sure if we need to say "if it can detect" when the keyword is "MAY." I think the choice here might be between SHOULD/MAY or MUST-if-detected. Regarding the choice of the error code, I think my mental model was that the use Structured Field is a layout requirement. But I agree that it's border line, I'm perfectly fine with using H3GENEALPROTOCOL_ERROR. We do not need a new error code for this - HTTP/3 stacks can always use the Reason Phrase field to communicate fine-grained information.

Revised text:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority  <ins> Field Value MAY be treated as a connection error.  In HTTP/2 the </ins> error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type  <ins> H3_GENERAL_PROTOCOL_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see h2-update-