jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-http

Commentary: reincarnated , because I messed up . Sorry , 
 LGTM but do n't forget push
Paragraph (version B):
If a DATA frame is received before a HEADERS frame on a either a
request or push stream, the recipient MUST respond with a connection
error of type HTTP_UNEXPECTED_FRAME (errors).
Draft: draft-ietf-quic-http

Commentary: by clearly splitting the two different error cases . 
 Moves existing text to be clearer , but does n't change the stated requirements . Editorial , and fine by me . 
 It 's unclear which error should be reported if an endpoint receives a second SETTINGS frame on any stream that 's not a control stream . Perhaps this should be explicitly defined in the draft ? 
 Hey I initially thought this was an editorial problem so created as an attempt to clarify things . However , I think the question is more philosophical . To analyse it a bit , what you 're asking is how to handle an error after the occurrence of a critical connection error . First , a SETTINGS frame on a wrong stream type , then another SETTINGS frame on a wrong stream . After the first critical error , all bets are off . I 'd expect a lot implementations to just give up at that stage as the peer is likely to be misbehaving . 
 I agree its an edge case but I do think it 'd be useful to exactly specify which of the two errors should be reported , especially when thinking of automated testing of HTTP/3 implementations . 
 I 'm sympathetic to that but I fear this could be a slippery slope towards adding lots of text for issues that occur after a critical close event . PRIORITY frames fall into a similar bucket , along with many of the server push frames and their validation rules . 
 I think the real unclarity in the spec is that both can happen simultaneously . After receiving a proper SETTINGS frame on the control channel , receiving a SETTINGS frame on some other stream would be both a second SETTINGS frame and a SETTINGS frame on the wrong stream . clarifies this reasonable . Thanks , both of you !
Paragraph (version A):
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see control-streams) by each peer, and MUST NOT be sent
subsequently or on any other stream.  If an endpoint receives a
SETTINGS frame on a different stream, the endpoint MUST respond with
a connection error of type HTTP_WRONG_STREAM.  If an endpoint
receives a second SETTINGS frame, the endpoint MUST respond with a
connection error of type HTTP_UNEXPECTED_FRAME.
Paragraph (version B):
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see control-streams) by each peer, and MUST NOT be sent
subsequently.  If an endpoint receives a second SETTINGS frame on the
control stream, the endpoint MUST respond with a connection error of
type HTTP_UNEXPECTED_FRAME.
Paragraph (version B):
SETTINGS frames MUST NOT be sent on any steam other than the control
stream.  If an endpoint receives a SETTINGS frame on a different
stream, the endpoint MUST respond with a connection error of type
HTTP_WRONG_STREAM.
Draft: draft-ietf-quic-http

Commentary: This pr changes the server 's error on receipt of a PUSHPROMISE frame . While the current draft implicitly suggests push promises can only be sent by the server , it does n't explicitly disallow clients from sending PUSHPROMISE frames . This pr explicitly disallows clients from sending PUSHPROMISE frames and requires the server to treat each receipt of a PUSHPROMISE frame as a connection error of type HTTPUNEXPECTEDFRAME .
Paragraph (version A):
If a PUSH_PROMISE frame is received on either control stream, the
recipient MUST respond with a connection error (errors) of type
HTTP_WRONG_STREAM.
Paragraph (version B):
If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error (errors) of type
HTTP_WRONG_STREAM.
Paragraph (version B):
A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type
HTTP_UNEXPECTED_FRAME.
Draft: draft-ietf-quic-http

Commentary: Receiving a HEADERS frame on a control stream should result in a connection error of type HTTPWRONGSTREAM . The correct error is documented for all other frame types except for HEADERS . This pr specifies the error for HEADERS frames as well . 
 This inconsistency was bugging me the other day . So thanks for beating me to fixing it :) iff gets traction , we 'd need a sweep of all these If a HEADERS frame is received on either control stream phrases to cover all streams ( exclusively or inclusively ) . 
 was closed . Is there anything else that 's blocking this pr from being merged ? 
 I so he can review and merge this .
Paragraph (version A):
HEADERS frames can only be sent on request / push streams.
Paragraph (version B):
HEADERS frames can only be sent on request / push streams.  If a
HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type HTTP_WRONG_STREAM.
Draft: draft-ietf-quic-http

Commentary: I 'm pretty sure the intent of was correct but the wrong error was changed in the draft . This pr makes the change that I think was intended in 
 Just a note . If this is the right answer and the PR lands , then will need to replace the new instance of HTTPMALFORMEDFRAME with something , e.g. HTTPINVALIDGOAWAY or something 
 Yeah , that crossed my mind . :-) YAEC ! 
 In , correctly observed that I messed up , but he closed his PR and I 'm not able to reopen it without more git wizardry than I 'm interested in practicing today . Easier just to fix it in my own branch .
Paragraph (version A):
The GOAWAY frame is always sent on the control stream.  It carries a
QUIC Stream ID for a client-initiated bidirectional stream encoded as
a variable-length integer.  A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type HTTP_WRONG_STREAM.
Paragraph (version B):
The GOAWAY frame is always sent on the control stream.  It carries a
QUIC Stream ID for a client-initiated bidirectional stream encoded as
a variable-length integer.  A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
The GOAWAY frame applies to the connection, not a specific stream.  A
client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (errors) of type HTTP_UNEXPECTED_FRAME.
Paragraph (version B):
The GOAWAY frame applies to the connection, not a specific stream.  A
client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (errors) of type HTTP_WRONG_STREAM.
Draft: draft-ietf-quic-http

Commentary: LGTM 
 S 5.2 . I do n't believe this is possible on UNIX . What system call do I use to generate  ? Neither close ( ) nor shutdown ( ) does it . 
 You set SO_LINGER to { 1 , 0 } , then close . 
 I do n't think there 's a question here about the -http draft , is there ? 
 The question is if it 's possible on standard OSes . Sounds like it is on Unix . How about Windows ? 
 This is the same requirement as in HTTP/2 . A " MUST ( but we know you probably wo n't ) " ? 
 Well , that was a joke in 6919 , so probably we should n't do that . 
 This is not that . We know that some implementations use TCP half - closed in HTTP . Some even rely on it to the point that things break if you do n't do it . Not that things do n't break for those people , but they have a narrow set of peers that they interact with . Of course , whether that set of endpoints is ALSO the same set of endpoints using CONNECT is hard to know . 
 Note that this particular issue is not about half - closed . In half - closed , you generate a FIN and then keep receiving data . This is about sending an RST . 
 Perhaps the text should be " SHOULD " , and if the platform does n't allow it , to " close the connection " . 
 There 's risk with that too , though . We encountered issues where the TCP connection was closed cleanly instead of aborted , and the client interpreted a truncated response as the ( cacheable ) response . It gets ugly . If you ca n't force a  on the other side , you perhaps should n't be implementing CONNECT . 
 Discussed in Tokyo ; MUST close the connection , SHOULD close with a RST .
Paragraph (version A):
A TCP connection error is signaled with QUIC RESET_STREAM frame.  A
proxy treats any error in the TCP connection, which includes
receiving a TCP segment with the RST bit set, as a stream error of
type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, a proxy
MUST send a TCP segment with the RST bit set if it detects an error
with the stream or the QUIC connection.
Paragraph (version B):
A TCP connection error is signaled with QUIC RESET_STREAM frame.  A
proxy treats any error in the TCP connection, which includes
receiving a TCP segment with the RST bit set, as a stream error of
type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, if a
proxy detects an error with the stream or the QUIC connection, it
MUST close the TCP connection.  If the underlying TCP implementation
permits it, the proxy SHOULD send a TCP segment with the RST bit set.
Draft: draft-ietf-quic-http

Commentary: This still seems like a pointless restriction to me , but it 's what we agreed in Tokyo , so here it is . 
 I think I share the concern ( though I am not sure how much I care ) . HTTP/3 is expected to allow extension frames to be used without coordination ; this PR forbids that to happen on a stream that uses the CONNECT method . 
 S 5.2 . Can you send anything other than DATA on a CONNECT stream ? You do n't say that I ca n't send anything else , but you do n't say I ca n't either . 
 It does n't mean anything ( because we have n't assigned semantics ) , but we should probably just forbid the use of other frames ( of those defined in this document ) . This is probably a shortcoming of 7540 as well . 
 Would n’t it be better to just prohibit the HEADERS frame ? We might want to introduce a frame that changes a property of a stream ( e.g. ,  bitrate ) . I do not think there ’s a strong reason to forbid such kind of extensions only on CONNECT stream . 
 I do n't want to prohibit extension frames , but the frames defined in the current spec do n't serve any purpose . That is why I said " of those defined in this document " . 
 Well , there 's technically nothing preventing the use of push .... ;-) More seriously , I do n't feel like the prohibition adds much . This maps the definition of the CONNECT method into H3 framing -- DATA frames = = TCP payload . In any other respect , it 's an HTTP request and frames mean what they otherwise mean . Is there a particular frame that needs to be prohibited ? HEADERS would indicate a trailer block ; it might be worth upstreaming to the updated semantic draft that a CONNECT tunnel ca n't have trailers . 
 Discussed in Tokyo ; after the CONNECT takes effect , all frames other than DATA are prohibited unless an extension specifically provides otherwise . 
 nits
Paragraph (version B):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other frame type MUST be treated as a connection error of type
HTTP_UNEXPECTED_FRAME.
Draft: draft-ietf-quic-http

Commentary: no text changes outside the Document Organization section . 
 Wow , this is a fun diff to review :-) 
 That 's why I pointed out that there are no actual text changes . But if it 's easier , you could open and in side - by - side browser windows . :-) I 'd like to land this fairly quickly ; from some experiments , other HTTP PRs merge into this just fine if they come after , but risk being summarily wiped out if merged before it . 
 It 's fine . The stream usage and request " lifecycle " sections are a bit too far apart , but I do n't know that I have a suggestion there . 
 S 3.2.2 . This is n't understandable without knowing what push is or what a PUSH promise is . Am I supposed to get that from 7540 ? In either case , you should clearly state that a push stream can only be used for a single push promise ( this is implied by the formatting ) . Happy to supply a PR if we can agree on what 's wanted ? 
 Yes , as currently written , a push stream corresponds 1:1 with a PUSH_PROMISE . Which is consistent again with 7540 ( we had a period where it was not ) . 
 Well . A push stream corresponds one - to - one with a push ID . You can duplicate promises using the DUPLICATE_PUSH frame . I think this is what was attempted to be described by the term " promised server push " as abstract from the frames that might get sent . If the language needs to improve to make this clearer then lets do it . 
 Does address this sufficiently , now that the description of push precedes this section ? There 's already a back - reference at the end of the paragraph if someone needs more details . 
 Closing ; please reopen if you feel that does not sufficiently address this . 
 It would be a lot easier to read the spec if the lifecycle ( which provides an overview of operation implicitly ) came before the packet formats . Happy to provide a PR , but no point if the editors do n't want it . 
 Thanks for the suggestion . I can see this either way . The ordering was intended to follow the HTTP/2 pattern of " framing layer , putting HTTP on the framing layer . " The QUIC spec 's new layout of successive layers of detail ( concepts , then specific mechanisms , then wire format ) would suggest putting frame specifics last . PR not necessary -- it 's a straightforward change if we decide to reorder this way . 
 I just suggested this change the other day , because I had the same issue . In particular , talking about the multiple push frames before introducing what push is is very awkward . 
 I like this new layout . Thanks  , this works for me !
Paragraph (version A):
A more detailed comparison between HTTP/2 and HTTP/3 can be found in
h2-considerations.
Paragraph (version B):
A more detailed comparison between HTTP/2 and HTTP/3 can be found
in h2-considerations.
Draft: draft-ietf-quic-http

Commentary: Skirts the editorial / design line . Previously , DUPLICATEPUSH referred to a Push ID in a previously - sent PUSHPROMISE frame ; that frame would have caused a connection error on arrival . This says that the error should be sent regardless of which frame arrives first . May need reconciling with . 
 Two questions : DUPLICATEPUSH respect  push ID limit ? PUSHPROMISE says the following : provided in a  frame ( Section 4.2.8 ) and MUST NOT use the same Push ID in multiple PUSHPROMISE frames should a client do if it sees a DUPLICATEPUSH for an ID of a PUSHPROMISE that it never received ? This could be caused by a race condition , so it seems sensible to allow this to clients to support this without error . We should probably document that like we did for other racy things . E.g. a  ID that has not yet been mentioned by a PUSH_PROMISE frame . 
 ( 2 ) is covered in : For ( 1 ) , yes it should -- the DUPLICATE might show up first , but the implication is that the ID has already been used in a PUSHPROMISE frame . If that would be invalid , we should be explicit that the DUPLICATEPUSH is also invalid . 
 SGTM 
 I think that we have a frame name problem , otherwise , this is fine . I think some wires got crossed in the suggested changes . Your comment points out that this might need reconciliation with but it seems to borrow the text directly from that PR . The outcome is that this PR is inconsistent with itself because at line the same error with PUSHPROMISE causes a MALFORMEDFRAME . I think the best path is to make this change be a MALFORMED_FRAME error and reconcile on if the group want that change .
Paragraph (version A):
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see frame-push-promise).
Paragraph (version B):
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see frame-push-promise), though that promise
might not be received before this frame.  A server MUST NOT use a
Push ID that is larger than the client has provided in a MAX_PUSH_ID
frame (frame-max-push-id).  A client MUST treat receipt of a
DUPLICATE_PUSH that contains a larger Push ID than the client has
advertised as a connection error of type HTTP_MALFORMED_FRAME.
Draft: draft-ietf-quic-recovery

Commentary: This should have been part of . 
 I applied your suggestions . I think this PR should be marked as editorial . 
 The new " MUST " threw me , but it 's not really new , is it ? 
 That one was introduced in already . 
 Seems reasonable to me . Throughout here , should we be using " peer " or " receiver " ? ( The suggestions I make here are not issues with this change , but I 'm sure that or will find them a home.)Thanks for fixing this .
Paragraph (version A):
smoothed_rtt uses path latency after adjusting RTT samples for peer-
reported host delays (host-delay).  A peer limits any delay in
sending an acknowledgement for an ack-eliciting packet to no greater
than the advertised max_ack_delay transport parameter.  Consequently,
when a peer reports an Ack Delay that is greater than its
max_ack_delay, the delay is attributed to reasons out of the peer's
control, such as scheduler latency at the peer or loss of previous
ACK frames.  Any delays beyond the peer's max_ack_delay are therefore
considered effectively part of path delay and incorporated into the
smoothed_rtt estimate.
Paragraph (version B):
The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for host delays (host-delay).  For packets sent in the
ApplicationData packet number space, a peer limits any delay in
sending an acknowledgement for an ack-eliciting packet to no greater
than the value it advertised in the max_ack_delay transport
parameter.  Consequently, when a peer reports an Ack Delay that is
greater than its max_ack_delay, the delay is attributed to reasons
out of the peer's control, such as scheduler latency at the peer or
loss of previous ACK frames.  Any delays beyond the peer's
max_ack_delay are therefore considered effectively part of path delay
and incorporated into the smoothed_rtt estimate.
Paragraph (version B):
MUST ignore the Ack Delay field of the ACK frame for packets sent
in the Initial and Handshake packet number space.
Draft: draft-ietf-quic-transport

Commentary: Just in case it was n't perfectly clear from the choice of words . 
 I know how you feel . We 'll be defining " the " eventually . I do n't know where the line is , but I think that it helps in this case to be doubly explicit . 
 I 'm wondering how one could possibly misinterpret " abandoning " here . Furthermore , I do n't think it 's relevant for the server here if the client actually discarded the connection state , as long as it does n't any more packets . 
 I do n't think we need to spend a lot of energy here . I agree that this does n't seem necessary , but I 'm not going to fight it either . 
 The draft currently reads : " When a client receives a Version Negotiation packet , it MUST abandon the current connection attempt . " However , it does not define what it is to abandon a connection attempt . Is it an abrupt termination without writing a connection close ? That probably makes the most sense since the server is meant to be stateless at this stage . 
 Do we really need to define " abandon " ? And if so , do n't we need to define what " discarding " means?LGTM
Paragraph (version A):
This system allows a server to process packets with unsupported
versions without retaining state.  Though either the Initial packet
or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt.
Paragraph (version B):
This system allows a server to process packets with unsupported
versions without retaining state.  Though either the Initial packet
or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt.  As a result, the
client discards all state for the connection and does not send any
more packets on the connection.
Draft: draft-ietf-quic-http

Commentary: This arises from a different discussion I had about the message exchange definition in section 5.1 . The description is correct but glosses over the detail of QPACK , which is mentioned very briefly later in section 5.1.1 . For complete accuracy , I would argue that a single message exchange may also contain one or more QPACK encoder instructions sent on the encoder stream .
Paragraph (version B):
The HEADERS and PUSH_PROMISE frames might reference updates to the
QPACK dynamic table.  While these updates are not directly part of
the message exchange, they must be received and processed before the
message can be consumed.  See header-formatting for more details.