jiebi/TextFlow huggingface dataset:
Original text:
HTTP/2 clients MUST indicate the target domain name when negotiating TLS. <del> Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only support and use the SNI extension; deployments of TLS 1.2 are subject to the requirements in the following sections.  Implementations are </del>  encouraged to provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance.

Reviewer comments:
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).

Revised text:
HTTP/2 clients MUST indicate the target domain name when negotiating TLS.  <ins> Requirements for deployments of HTTP/2 that negotiate TLS13 are included in tls13features.  Deployments of TLS 1.2 are subject to the requirements in tls12features and tls12ciphers.  Implementations are </ins> encouraged to provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance.
Original text:
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- <del> Hellman (DHE) TLS12 and 224 bits for cipher suites that use ephemeral </del>  elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of

Reviewer comments:
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).

Revised text:
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie-  <ins> Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral </ins> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of
Original text:
HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected.  10. 10.1.

Reviewer comments:
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).

Revised text:
HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. <ins> 9.2.3. TLS 1.3 includes a number of features not available in earlier versions.  This section discusses the use of these features. HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat a TLS post- handshake CertificateRequest message as a ConnectionErrorHandler of type PROTOCOL_ERROR. The prohibition on post-handshake authentication applies even if the client offered the "post_handshake_auth" TLS extension.  Post- handshake authentication support might be advertised independently of TLS-ALPN.  Clients might offer the capability for use in other protocols, but inclusion of the extension cannot imply support within HTTP/2. TLS13 defines other post-handshake messages, NewSessionTicket and KeyUpdate, which can be used as they have no direct interaction with HTTP/2.  Unless the use of a new type of TLS message depends on an interaction with the application-layer protocol, that TLS message can be sent after the handshake completes. TLS early data MAY be used to send requests, provided that the guidance in RFC8470 is observed.  Clients send requests in early data assuming initial values for all server settings. </ins> 10. 10.1.
Original text:
10.7. Padding within HTTP/2 is not intended as a replacement for general <del> purpose padding, such as might be provided by TLS12.  Redundant </del>  padding could even be counterproductive.  Correct application can depend on having specific knowledge of the data that is being padded.

Reviewer comments:
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).

Revised text:
10.7. Padding within HTTP/2 is not intended as a replacement for general  <ins> purpose padding, such as might be provided by TLS13.  Redundant </ins> padding could even be counterproductive.  Correct application can depend on having specific knowledge of the data that is being padded.
Original text:
As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined <del> in HTML5. </del>  HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site.  Reusing connections for

Reviewer comments:
The thinking has evolved considerably since the original reference was made. This is the right way to refer to this concept.
So the re-request review button doesn't appear to work; NAME any objections to landing this with the new reference target?
The current reference is in the WHATWG "infra standard": URL To use this, we need to ask for the "tracking-vector" anchor to be made permanent.
URL filed. I have changes for a pull request .
I'm a bit surprised you chose infra; the fingerprinting guidance document in the W3C is much more complete. There are also tons of academic references that have better descriptions; to start, Eckersley's original paper.
I was looking for a direct replacement, which is what that is. I can cite URL if you think that is better. Or URL if that makes more sense. I never know which is better.
Probably the TR - whatever bibxml says, I'd think.
I'm going to go with something simpler. RFC 6973 has an adequate definition.
None whatsoever.

Revised text:
As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined  <ins> in PRIVACY. </ins> HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site.  Reusing connections for
Original text:
receives an unexpected stream identifier MUST respond with a ConnectionErrorHandler of type PROTOCOL_ERROR. <del> The first use of a new stream identifier implicitly closes all streams in the "idle" state that might have been initiated by that peer with a lower-valued stream identifier.  For example, if a client sends a HEADERS frame on stream 7 without ever sending a frame on stream 5, then stream 5 transitions to the "closed" state when the first frame for stream 7 is sent or received. </del>  Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream

Reviewer comments:
This is a first stab at . I've gone for a minimal change here, simply clarifying that only HEADERS and PUSHPROMISE frames have the effect of implicitly closing streams. While I was writing this I did have a question that may need to be raised on-list: do HEADERS and PUSHPROMISE only implicitly close streams if they are accepted? That is, if a client sends a HEADERS frame that triggers a stream error, does that HEADERS frame still implicitly close all streams with a lower stream ID that are in the "idle" state? This may also be worth clarifying.
Like it. Take the first, maybe take the second, and we can merge this one.

Revised text:
receives an unexpected stream identifier MUST respond with a ConnectionErrorHandler of type PROTOCOL_ERROR.  <ins> A HEADERS frame will transition the client-initiated stream identified by the stream identifier in the frame header from "idle" to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </ins> Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream
Original text:
supports HTTP/2. The means by which support for HTTP/2 is determined is different for <del> "http" and "https" URIs.  Discovery for "http" URIs is described in discover-http.  Discovery for "https" URIs is described in discover- https. </del>  3.1.

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:
supports HTTP/2. The means by which support for HTTP/2 is determined is different for  <ins> "http" and "https" URIs.  Discovery for "https" URIs is described in discover-https.  HTTP/2 support for "http" URIs can only be discovered by out-of-band means, and requires prior knowledge of the support as described in known-http. </ins> 3.1.
Original text:
Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader. <del> 3.4. </del>  A client can learn that a particular server supports HTTP/2 by other means.  For example, ALT-SVC describes a mechanism for advertising

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:
Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader.  <ins> 3.3. </ins> A client can learn that a particular server supports HTTP/2 by other means.  For example, ALT-SVC describes a mechanism for advertising
Original text:
to change, for configurations to differ between instances in clustered servers, or for network conditions to change. <del> 3.5. </del>  In HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the

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:
to change, for configurations to differ between instances in clustered servers, or for network conditions to change.  <ins> 3.4. </ins> In HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the
Original text:
. This sequence MUST be followed by a SETTINGS frame (SETTINGS), which MAY be empty.  The client sends the client connection preface <del> immediately upon receipt of a 101 (Switching Protocols) response (indicating a successful upgrade) or as the first application data octets of a TLS connection.  If starting an HTTP/2 connection with prior knowledge of server support for the protocol, the client connection preface is sent upon connection establishment. </del>  The server connection preface consists of a potentially empty SETTINGS frame (SETTINGS) that MUST be the first frame the server

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:
. This sequence MUST be followed by a SETTINGS frame (SETTINGS), which MAY be empty.  The client sends the client connection preface  <ins> as the first application data octets of a connection. </ins> The server connection preface consists of a potentially empty SETTINGS frame (SETTINGS) that MUST be the first frame the server