One is that it might be too restrictive. We do not know what other priority schemes we'd see in the future. Consider the case where we'd have a frame-based prioritization scheme that is dedicated to video requests, while the other streams would be using the Priority headers. In such case, there is no reason to prohibit either of the two from being sent until the client learns that the SETTINGS have been received.
The other problem is that H3 does not define a way to acknowledge the receipt of SETTINGS at the application-protocol level. It is my understanding that H3 (including QPACK) is designed to have it's own ACKs for signaling the receipt, rather than relying on transport-level ACKs. This normative text violates that principle.
Considering these aspects, I think that we should paraphrase this these sentences discussing HTTP/3 to something like: In HTTP/3, SETTINGS may arrive after the first request even if they are sent first. Future specifications that define alternative prioritization schemes SHOULD define how the server would act when it receives stream-level priority signals prior to receiving the SETTINGS frame.
IMO, there are two problems with the text.
One is that it might be too restrictive. We do not know what other priority schemes we'd see in the future. Consider the case where we'd have a frame-based prioritization scheme that is dedicated to video requests, while the other streams would be using the Priority headers. In such case, there is no reason to prohibit either of the two from being sent until the client learns that the SETTINGS have been received.
The other problem is that H3 does not define a way to acknowledge the receipt of SETTINGS at the application-protocol level. It is my understanding that H3 (including QPACK) is designed to have it's own ACKs for signaling the receipt, rather than relying on transport-level ACKs. This normative text violates that principle.
Considering these aspects, I think that we should paraphrase this these sentences discussing HTTP/3 to something like: In HTTP/3, SETTINGS may arrive after the first request even if they are sent first. Future specifications that define alternative prioritization schemes SHOULD define how the server would act when it receives stream-level priority signals prior to receiving the SETTINGS frame.
Originally posted by @kazuho in https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/58