jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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> <ins> offered for other protocols. </ins> 10.3.
Code change:
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.

Related discussion:
text: 11.5. <del> This section registers the </del> <ins> This section marks the </ins> <del> header field in the "Permanent Message Header Field Names" registry BCP90. </del> <ins> header field registered in RFC7540 as obsoleted. </ins> 11.6.
Code change:
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.

Related discussion:
text: 11.7. <del> This document registers the "h2c" upgrade token in the "HTTP Upgrade Tokens" registry (HTTP). </del> <ins> Previous versions of this document (RFC7540) registered an upgrade token.  This capability has been removed: see versioning. </ins>
Code change:
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.

Related discussion:
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> <ins> receiving the 101 response, the client sends a SessionHeader, which </ins> includes a SETTINGS frame. 2.3.
Code change:
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.

Related discussion:
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> <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-
Code change:
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.

Related discussion:
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> <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 <del> existing clients send a Content-Length header field, which caused server implementations have come to depend upon its presence. </del> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <ins> settings prior to receiving any frames from the server. </ins> 3.3.
Code change:
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.

Related discussion:
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> <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 <del> honor any parameters established.  In some configurations, it is </del> <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.
Code change:
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.

Related discussion:
text: The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.  The SETTINGS frame is also used to acknowledge the <del> receipt of those parameters.  Individually, a SETTINGS parameter can also be referred to as a "setting". </del> <ins> receipt of those settings.  Individually, a configuration parameter from a SETTINGS frame is referred to as a "setting". </ins> <del> SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same parameter can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </del> <ins> Settings are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same setting can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </ins> A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection.  Implementations MUST support all of <del> the parameters defined by this specification. </del> <ins> the settings defined by this specification. </ins> Each parameter in a SETTINGS frame replaces any existing value for <del> that parameter.  Parameters are processed in the order in which they </del> <ins> that parameter.  Settings are processed in the order in which they </ins> appear, and a receiver of a SETTINGS frame does not need to maintain <del> any state other than the current value of its parameters.  Therefore, </del> <ins> any state other than the current value of each setting.  Therefore, </ins> the value of a SETTINGS parameter is the last value that is seen by a receiver. <del> SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: </del> <ins> SETTINGS frames are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the ACK flag: </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a SETTINGS frame MUST be zero (0x0).  If an
Code change:
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.

Related discussion:
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> <ins> settings, each consisting of an unsigned 16-bit setting identifier </ins> and an unsigned 32-bit value. 6.5.2. <del> The following parameters are defined: </del> <ins> The following settings are defined: </ins> An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting.
Code change:
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.

Related discussion:
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> <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 <del> parameters MUST be ignored.  Once all values have been processed, the </del> <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 <del> sender of the altered parameters can rely on the setting having been </del> <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
Code change:
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?

Related discussion:
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> <ins> Transfer Protocol version 2 (HTTP/2)" section. </ins> This document registers the
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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
Code change:
The language doesn't properly acknowledge the possibility that some processing might have been performed before an error is detected. This could use some tweaking.
Proposal here: URL
Seems like a reasonable change.
Seems like a nice clear improvement

Related discussion:
text: For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed <del> response.  Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </del> <ins> response. Endpoints that progressively process messages might have performed some processing before identifying a request or response as malformed.  For instance, it might be possible to generate an informational or 404 status code without having received a complete request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </ins> 8.1.3.
Code change:
This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.

Related discussion:
text: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 <del> Frame Type" registry operates under either of the RFC5226 for values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for Experimental Use. </del> <ins> Frame Type" registry operates under either of the RFC8126 or RFC8126 policies. </ins> New entries in this registry require the following information:
Code change:
This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.

Related discussion:
text: This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 <del> Settings" registry operates under the RFC5226 for values in the range from 0x0000 to 0xefff, with values between and 0xf000 and 0xffff being reserved for Experimental Use. </del> <ins> Settings" registry operates under the RFC8126. </ins> New registrations are advised to provide the following information:
Code change:
This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.

Related discussion:
text: This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 <del> Error Code" registry operates under the RFC5226. </del> <ins> Error Code" registry operates under the RFC8126. </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new