jiebi/TextFlow huggingface dataset:
Original text:
messages; the stream identifier of zero cannot be used to establish a new stream. <del> HTTP/1.1 requests that are upgraded to HTTP/2 (see discover-http) are responded to with a stream identifier of one (0x1).  After the upgrade completes, stream 0x1 is "half-closed (local)" to the client. Therefore, stream 0x1 cannot be selected as a new stream identifier by a client that upgrades from HTTP/1.1. </del> The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved.  This governs streams that are opened using a HEADERS frame

Reviewer comments:
HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.

Revised text:
messages; the stream identifier of zero cannot be used to establish a new stream.  The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved.  This governs streams that are opened using a HEADERS frame
Original text:
The cleartext version of HTTP/2 has minimal protection against cross- protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is <del> offered for other protocols.  A server that is willing to ignore parts of an HTTP/1.1 request containing an Upgrade header field in addition to the client connection preface could be exposed to a cross-protocol attack. </del>  10.3.

Reviewer comments:
HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.

Revised text:
The cleartext version of HTTP/2 has minimal protection against cross- protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is  <ins> offered for other protocols. </ins> 10.3.
Original text:
11.5. <del> This section registers the </del>  <del> header field in the "Permanent Message Header Field Names" registry BCP90. </del>  11.6.

Reviewer comments:
HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.

Revised text:
11.5.  <ins> This section marks the </ins>  <ins> header field registered in RFC7540 as obsoleted. </ins> 11.6.
Original text:
11.7. <del> This document registers the "h2c" upgrade token in the "HTTP Upgrade Tokens" registry (HTTP). </del> 

Reviewer comments:
HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.

Revised text:
11.7.  <ins> Previous versions of this document (RFC7540) registered an upgrade token.  This capability has been removed: see versioning. </ins>
Original text:
initiated the Upgrade. The first HTTP/2.0 frame sent by the server is a SETTINGS.  Upon <del> receiving the 101 response, the client sents a SessionHeader, which </del>  includes a SETTINGS frame. 2.3.

Reviewer comments:
Additionally, section 4.2.3 contains a lot of text that is similar to 4.2.2, but there may be a reason for that.
I'll try to remember to fix the content-length thing.

Revised text:
initiated the Upgrade. The first HTTP/2.0 frame sent by the server is a SETTINGS.  Upon  <ins> receiving the 101 response, the client sends a SessionHeader, which </ins> includes a SETTINGS frame. 2.3.
Original text:
portion of the request-target (e.g. "https") All header field names MUST be lowercased, and the definitions of <del> all header fields names defined by HTTP/1.1 are updated to be all </del>  lowercase. The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-

Reviewer comments:
Additionally, section 4.2.3 contains a lot of text that is similar to 4.2.2, but there may be a reason for that.
I'll try to remember to fix the content-length thing.

Revised text:
portion of the request-target (e.g. "https") All header field names MUST be lowercased, and the definitions of  <ins> all header field names defined by HTTP/1.1 are updated to be all </ins> lowercase. The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-
Original text:
Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header field.  First, it informs the <del> server of how much data to expect, which the server can used to track </del>  overall progress and provide appropriate user feedback.  More importantly, some HTTP server implementations fail to correctly process requests that omit the Content-Length header field.  Many <del> existing clients send a Content-Length header field, which caused server implementations have come to depend upon its presence. </del>  The user-agent is free to prioritize requests as it sees fit.  If the user-agent cannot make progress without receiving a resource, it

Reviewer comments:
Additionally, section 4.2.3 contains a lot of text that is similar to 4.2.2, but there may be a reason for that.
I'll try to remember to fix the content-length thing.

Revised text:
Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header field.  First, it informs the  <ins> server of how much data to expect, which the server can use to track </ins> overall progress and provide appropriate user feedback.  More importantly, some HTTP server implementations fail to correctly process requests that omit the Content-Length header field.  Many  <ins> existing clients send a Content-Length header field, and some server implementations have come to depend upon its presence. </ins> The user-agent is free to prioritize requests as it sees fit.  If the user-agent cannot make progress without receiving a resource, it
Original text:
header field.  The header field is a connection-specific header field that includes <del> parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. </del>  A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present.  A server MUST

Reviewer comments:
In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.

Revised text:
header field.  The header field is a connection-specific header field that includes  <ins> settings that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. </ins> A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present.  A server MUST
Original text:
SETTINGS frame.  Explicit SettingsSync is not necessary, since a 101 response serves as implicit acknowledgement.  Providing these values in the upgrade request gives a client an opportunity to provide <del> parameters prior to receiving any frames from the server. </del>  3.3.

Reviewer comments:
In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.

Revised text:
SETTINGS frame.  Explicit SettingsSync is not necessary, since a 101 response serves as implicit acknowledgement.  Providing these values in the upgrade request gives a client an opportunity to provide  <ins> settings prior to receiving any frames from the server. </ins> 3.3.
Original text:
additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface.  It is important to note, however, that the server <del> connection preface SETTINGS frame might include parameters that </del>  necessarily alter how a client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to <del> honor any parameters established.  In some configurations, it is </del>  possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.

Reviewer comments:
In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.

Revised text:
additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface.  It is important to note, however, that the server  <ins> connection preface SETTINGS frame might include settings that </ins> necessarily alter how a client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to  <ins> honor any settings established.  In some configurations, it is </ins> possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
Original text:
6.5.1. The frame payload of a SETTINGS frame consists of zero or more <del> parameters, each consisting of an unsigned 16-bit setting identifier </del>  and an unsigned 32-bit value. 6.5.2. <del> The following parameters are defined: </del>  An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting.

Reviewer comments:
In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.

Revised text:
6.5.1. The frame payload of a SETTINGS frame consists of zero or more  <ins> settings, each consisting of an unsigned 16-bit setting identifier </ins> and an unsigned 32-bit value. 6.5.2.  <ins> The following settings are defined: </ins> An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting.
Original text:
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the <del> updated parameters as soon as possible upon receipt. </del>  The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported <del> parameters MUST be ignored.  Once all values have been processed, the </del>  recipient MUST immediately emit a SETTINGS frame with the ACK flag set.  Upon receiving a SETTINGS frame with the ACK flag set, the <del> sender of the altered parameters can rely on the setting having been </del>  applied. If the sender of a SETTINGS frame does not receive an acknowledgement

Reviewer comments:
In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.

Revised text:
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the  <ins> updated settings as soon as possible upon receipt. </ins> The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported  <ins> settings MUST be ignored.  Once all values have been processed, the </ins> recipient MUST immediately emit a SETTINGS frame with the ACK flag set.  Upon receiving a SETTINGS frame with the ACK flag set, the  <ins> sender of the altered settings can rely on the value having been </ins> applied. If the sender of a SETTINGS frame does not receive an acknowledgement
Original text:
This document establishes a registry for frame types, settings, and error codes.  These new registries appear in the new "Hypertext <del> Transfer Protocol version 2 (HTTP/2) Parameters" section. </del>  This document registers the

Reviewer comments:
From IANA: As we have the patient open already, it might be OK to change the registry name to follow modern conventions.
To clarify, IANA would like us to delete the word "Parameters" from the following text?

Revised text:
This document establishes a registry for frame types, settings, and error codes.  These new registries appear in the new "Hypertext  <ins> Transfer Protocol version 2 (HTTP/2)" section. </ins> This document registers the
Original text:
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.  Discussion Venues

Reviewer comments:
The current rules state that you need to include text in abstract and introduction. This will result in redundant entries for the specs with other changes that add 7540 references, but we can sort that out later.
Picking my battles more judiciously (as much as I'd like to fight this one, it's a low reward, high risk situation).
informatively, as they are obsoleted by this spec
Rules are boring. Be a rebel without a pause. Omit that text.

Revised text:
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged. <ins> This document obsoletes RFC 7540 and RFC 8740. </ins> Discussion Venues
Original text:
Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.  2. HTTP/2 provides an optimized transport for HTTP semantics.  HTTP/2

Reviewer comments:
The current rules state that you need to include text in abstract and introduction. This will result in redundant entries for the specs with other changes that add 7540 references, but we can sort that out later.
Picking my battles more judiciously (as much as I'd like to fight this one, it's a low reward, high risk situation).
informatively, as they are obsoleted by this spec
Rules are boring. Be a rebel without a pause. Omit that text.

Revised text:
Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing. <ins> This document obsoletes RFC7540 and RFC8740. </ins> 2. HTTP/2 provides an optimized transport for HTTP semantics.  HTTP/2
Original text:
8.1.2.1. <del> While HTTP/1.x used the message start-line (see HTTP11) to convey control data, HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) for this purpose. Pseudo-header fields are not HTTP header fields.  Pseudo-header fields contain control data (see HTTP).  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </del>  Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear

Reviewer comments:
This required a little careful rewriting of text that only recently rewrote. Hopefully this retains the improvements of that rewrite.
Right now, we have a lot of 1.1-specific language. In theory, it should be possible to remove 1.1 references and use core HTTP semantics to describe the protocol elements. That would be much cleaner, but it could be tricky.
Nice. I think the retains the original meaning of the text well enough, and is as clear as it can be without ever needing to normatively invoke HTTP/1.1. Needle well threaded.

Revised text:
8.1.2.1.  <ins> HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </ins> Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear