Original text:
The header of the request message is carried by a PUSH_PROMISE frame (see frame-push-promise) on the request stream which generated the <del> push.  This allows the server push to be associated with a client request.  Promised requests MUST conform to the requirements in </del>  Section 8.2 of HTTP2. <del> The same server push can be associated with additional client requests using a DUPLICATE_PUSH frame (see frame-duplicate-push). </del>  Ordering of a PUSH_PROMISE or DUPLICATE_PUSH in relation to certain parts of the response is important.  The server SHOULD send

Reviewer comments:
I decided to keep this pretty simple and leave the use or lack thereof unspecified, since we already know there's variation there. I was hoping to avoid creating conflicts with , but it made more sense to pull the association references into the same paragraph, which that PR also touches. Sorry, NAME Editorial-ish -- explicitly states a MAY that was previously implicit.
IIUC, since this is editorial it be merged before Ryan's PR that removes DUPLICATEPUSH in order to solve the design issue . Once merged, Ryan will need to remove the sentence and the paragraph will still stand correct?
Instead of just removing the sentence, probably replace it with a sentence about sending multiple PUSH_PROMISES to associate with multiple streams, but basically.
NAME and I had an enlightening discussion on , which highlighted a philosophical difference in our view of how push works, the filters through which we read RFC 7540, and the purpose of PUSHPROMISE on multiple streams. It might be worth expanding the text in HTTP/3 to give the reader the sense of both viewpoints, especially since disagreement between server and client implementations might have some sharp edges. RFC 7540 says: This "association" is only leveraged one other place in H2 directly; the push response is dependent on the associated stream for priority purposes. What does it mean to be "associated"? One implementation path ignores it totally, keeping a global cache of pending pushes. In this viewpoint, the purpose of PUSHPROMISE on multiple streams is to make sure that some PUSHPROMISE arrives before a reference to a resource that's being pushed, so the client knows it's already coming and can suppress requests. Subsequent PUSHPROMISEs are entirely superfluous. Another view says that pushes are tied to requests which are related, and might not be applicable to a request for that resource made in a different context (different navigations, different clients of a proxy, etc.); this is especially true if the response is not cacheable. In this viewpoint, the purpose of PUSHPROMISE/DUPLICATEPUSH is to signal which request contexts the pushed response is applicable to. These views are mostly identical if the response is cacheable or has appropriate Vary headers set, but they're subtly different views of the system.
Yeah, this works for me.Other than conflicting with (/me shakes his fist!) this looks good to me. I appreciate the neutrality around the interpretation of association.

Revised text:
The header of the request message is carried by a PUSH_PROMISE frame (see frame-push-promise) on the request stream which generated the  <ins> push.  Promised requests MUST conform to the requirements in </ins> Section 8.2 of HTTP2.  <ins> Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the PUSH_PROMISE frame was received.  The same server push can be associated with additional client requests using a DUPLICATE_PUSH frame (see frame-duplicate-push).  These associations do not affect the operation of the protocol, but MAY be used by user agents when deciding how to use pushed resources. </ins> Ordering of a PUSH_PROMISE or DUPLICATE_PUSH in relation to certain parts of the response is important.  The server SHOULD send