jiebi/TextFlow huggingface dataset:
Original text:
This section marks the <del> header field registered in RFC7540 as obsoleted.  The registration is updated to include the details as required by HTTP: </del>  11.6.

Reviewer comments:
The HTTP2-Settings header field and the h2c Upgrade token are both obsolete in the same way for the same reason, but it's rendered differently in their respective IANA sections. HTTP2-Settings is marked as Obsolete in the registry, with a reference back to the IANA Considerations of this document h2c gives no instructions to IANA, but includes explanatory text that the capability is removed and refers to Section 3.1. I would suggest that these should be aligned and combined, such that each one does two things: Instructs IANA to mark the entry as Obsolete Add a note that the element was used for Upgrade and reference Section 3.1 for more detail on Upgrade's removal

Revised text:
This section marks the  <ins> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins> 11.6.
Original text:
11.7. <del> RFC7540 registered an upgrade token.  This capability has been removed: see versioning. </del> 

Reviewer comments:
The HTTP2-Settings header field and the h2c Upgrade token are both obsolete in the same way for the same reason, but it's rendered differently in their respective IANA sections. HTTP2-Settings is marked as Obsolete in the registry, with a reference back to the IANA Considerations of this document h2c gives no instructions to IANA, but includes explanatory text that the capability is removed and refers to Section 3.1. I would suggest that these should be aligned and combined, such that each one does two things: Instructs IANA to mark the entry as Obsolete Add a note that the element was used for Upgrade and reference Section 3.1 for more detail on Upgrade's removal

Revised text:
11.7.  <ins> This section records the upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as follows: </ins>
Original text:
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the <del> absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </del>  A request or response that includes message content can include a

Reviewer comments:
Only pseudo-header fields can be mandatory, so no point saying anything about fields more generally here.
sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see Section 8.2). Are there any mandatory fields that are not pseudo-header fields?

Revised text:
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the  <ins> absence of mandatory pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </ins> A request or response that includes message content can include a
Original text:
not use TLS. Once TLS negotiation is complete, both the client and the server MUST <del> send a ConnectionHeader. </del>  3.3.

Reviewer comments:
As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.

Revised text:
not use TLS. Once TLS negotiation is complete, both the client and the server MUST  <ins> send a preface. </ins> 3.3.
Original text:
a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP <del> connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </del>  <del> Likewise, the server MUST send a ConnectionHeader. </del>  Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future

Reviewer comments:
As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.

Revised text:
a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP  <ins> connection and send the preface followed by HTTP/2 frames.  Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins>  <ins> Likewise, the server MUST send a preface. </ins> Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future
Original text:
defining new methods, status codes, or fields (see HTTP). Extensions are permitted to use new FrameHeader, new SETTINGS, or new <del> ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </del>  Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames

Reviewer comments:
As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.

Revised text:
defining new methods, status codes, or fields (see HTTP). Extensions are permitted to use new FrameHeader, new SETTINGS, or new  <ins> ErrorCodes.  Registries for managing these extension points are defined in RFC7540. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames
Original text:
protocol. The cleartext version of HTTP/2 has minimal protection against cross- <del> protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. </del>  10.3.

Reviewer comments:
As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.

Revised text:
protocol. The cleartext version of HTTP/2 has minimal protection against cross-  <ins> protocol attacks.  The preface contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. </ins> 10.3.
Original text:
to HTTP/2, but are not redefined in this document. [RFC Editor: please remove this paragraph.]  IANA is requested to <del> update references in these registries to refer to this document.  The registration of the </del>  method needs to be updated to refer to preface; all other section numbers have not changed.

Reviewer comments:
Includes changes from , as that hits the same paragraph.
why is c4d3528 included?
Hmm, poor rebase on my part I think. I made , you made the changes there, then I made a branch for this and then rebased on top of . It should go away when merged.

Revised text:
to HTTP/2, but are not redefined in this document. [RFC Editor: please remove this paragraph.]  IANA is requested to  <ins> update references to RFC 7540 in the following registries to refer to this document: Application-Layer Protocol Negotiation (ALPN) Protocol IDs, HTTP/2 Frame Type, HTTP/2 Settings, HTTP/2 Error Code, and HTTP Method Registry.  The registration of the </ins> method needs to be updated to refer to preface; all other section numbers have not changed.
Original text:
This section marks the <del> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </del>  11.2. This section records the <del> upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as </del>  follows:

Reviewer comments:
Includes changes from , as that hits the same paragraph.
why is c4d3528 included?
Hmm, poor rebase on my part I think. I made , you made the changes there, then I made a branch for this and then rebased on top of . It should go away when merged.

Revised text:
This section marks the  <ins> header field registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Field Name Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins> 11.2. This section records the  <ins> upgrade token registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated as </ins> follows:
Original text:
All numeric values are in network byte order.  Values are unsigned unless otherwise indicated.  Literal values are provided in decimal or hexadecimal as appropriate.  Hexadecimal literals are prefixed <del> with </del>  <del> to distinguish them from decimal literals. </del>  This specification describes binary formats using the convention described in QUIC.  Note that this format uses network byte order and

Reviewer comments:
A recent xml2rfc update changed the way that the element was rendered in text. Take advantage of that by adding quotes to strings that really do benefit from additional quoting, such as the "PRI ..." preface string. Most of the changes shown in a recent diff are down to losing quotes on header field names and other protocol elements. These do not need to be quoted for their meaning to be clear and unambiguous. The use of for these items improves the HTML rendering, but the loss of line noise in text renderings is a net win (at least in my opinion).
I agree with your reasoning, this seems like a good change.

Revised text:
All numeric values are in network byte order.  Values are unsigned unless otherwise indicated.  Literal values are provided in decimal or hexadecimal as appropriate.  Hexadecimal literals are prefixed  <ins> with " </ins>  <ins> " to distinguish them from decimal literals. </ins> This specification describes binary formats using the convention described in QUIC.  Note that this format uses network byte order and
Original text:
The client connection preface starts with a sequence of 24 octets, which in hex notation is: <del> That is, the connection preface starts with the string </del>  <del> . This sequence MUST be followed by a SETTINGS frame (SETTINGS), </del>  which MAY be empty.  The client sends the client connection preface as the first application data octets of a connection.

Reviewer comments:
A recent xml2rfc update changed the way that the element was rendered in text. Take advantage of that by adding quotes to strings that really do benefit from additional quoting, such as the "PRI ..." preface string. Most of the changes shown in a recent diff are down to losing quotes on header field names and other protocol elements. These do not need to be quoted for their meaning to be clear and unambiguous. The use of for these items improves the HTML rendering, but the loss of line noise in text renderings is a net win (at least in my opinion).
I agree with your reasoning, this seems like a good change.

Revised text:
The client connection preface starts with a sequence of 24 octets, which in hex notation is:  <ins> That is, the connection preface starts with the string " </ins>  <ins> ".  This sequence MUST be followed by a SETTINGS frame (SETTINGS), </ins> which MAY be empty.  The client sends the client connection preface as the first application data octets of a connection.
Original text:
The HEADERS+PRIORITY frame is identical to the HEADERS, preceded by a single reserved bit and a 31-bit priority; see StreamPriority. <del> No type-specific flags are defined. </del>  HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is

Reviewer comments:
Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:

Revised text:
The HEADERS+PRIORITY frame is identical to the HEADERS, preceded by a single reserved bit and a 31-bit priority; see StreamPriority.  <ins> HEADERS+PRIORITY uses exactly the same flags as the HEADERS frame. See HEADERS for any flags. </ins> HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is
Original text:
PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </del>  unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see

Reviewer comments:
Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:

Revised text:
PushResources contains a thorough description of the use of PUSH_PROMISE frames.  <ins> The payload of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see