Draft: draft-ietf-quic-http

Commentary: 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 , Editorial - ish -- explicitly states a MAY that was previously implicit . 
 IIUC , since this is editorial it be merged before  's PR that removes DUPLICATEPUSH in order to solve the design issue . Once merged ,  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 . 
 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 / DUPLICATE_PUSH 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  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 .
Paragraph (version A):
The header of the request message is carried by a PUSH_PROMISE frame
(see frame-push-promise) on the request stream which generated the
push.  This allows the server push to be associated with a client
request.  Promised requests MUST conform to the requirements in
Section 8.2 of HTTP2.
Paragraph (version A):
The same server push can be associated with additional client
requests using a DUPLICATE_PUSH frame (see frame-duplicate-push).
Paragraph (version B):
The header of the request message is carried by a PUSH_PROMISE frame
(see frame-push-promise) on the request stream which generated the
push.  Promised requests MUST conform to the requirements in
Section 8.2 of HTTP2.
Paragraph (version B):
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.