jiebi/CodeConvo huggingface dataset:
Code change:
As stated in , it's misleading and contradictory. Better to concentrate on configuration for this, as that is the common usage.
Section 3.3 says the following about cleartext HTTP/2: I had previously conceived of Alt-Svc as requiring a certificate and TLS, but that's not strictly true. RFC 7838 says that a client MUST have reasonable assurances, and a TLS cert is one way to do that. It also says that the connection must have equal or better security properties, which implies you can't go from TLS to non-TLS. This statement suggests that it's valid to offer on an http:// URI if your server can accept direct-to-H2 connections, but doesn't explicitly say so. Is that the intended reading here? But RFC 7838 says: Perhaps that doesn't apply, because the alternative is the same server on the same TCP port. Still, I feel like this waves at Alt-Svc for a use which is, at best, under-specified; at worst, not actually possible.

Related discussion:
text: 3.3. A client can learn that a particular server supports HTTP/2 by other <del> means.  For example, ALT-SVC describes a mechanism for advertising this capability. A client MUST send the ConnectionHeader and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del> <ins> means.  For example, a client could be configured with knowledge that a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP 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; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.
Code change:
This text wasn't actually changed in , but I noticed it while reviewing. This says that implementations which support TLS MUST use ALPN, but that's not really tied to what the implementation supports -- it's tied to what the current connection is doing. If you support TLS but are using cleartext TCP for the current connection (regardless of why), you're not required to use ALPN.

Related discussion:
text: 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 <del> connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del> <ins> connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.
Code change:
The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).

Related discussion:
text: HTTP/2 uses DATA frames to carry message content.  The <del> transfer encoding defined in HTTP11 cannot be used in HTTP/2. </del> <ins> transfer encoding defined in HTTP11 cannot be used in HTTP/2; see ConnectionSpecific. </ins> Trailer fields are carried in a field block that also terminates the stream.  That is, trailer fields comprise a sequence starting with a
Code change:
The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).

Related discussion:
text: header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing <del> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed. </del> <ins> connection-specific header fields.  This includes the header field and those listed as having connection-specific semantics in HTTP (that is, , , , and ).  Any message containing connection-specific header fields MUST be treated as malformed. </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any
Code change:
I know that Cory beat me to it with , but I had written text. I only forgot to make the PR. Cory can decide which he likes better :)
In the aside about HTTP/2 deliberately not supporting Upgrade, it feels worth mentioning that we later partially reversed ourselves and brought back a moral equivalent of Upgrade with a less obvious name. Reference to RFC8441 appropriate here?
You put more things in your citation block, so it’s clearly better.

Related discussion:
text: status code (HTTP). The semantics of 101 (Switching Protocols) aren't applicable to a <del> multiplexed protocol.  Alternative protocols are able to use the same </del> <ins> multiplexed protocol.  Similar functionality might be enabled through the use of RFC8441 and other protocols are able to use the same </ins> mechanisms that HTTP/2 uses to negotiate their use (see starting). 8.7.
Code change:
The code for the IANA policies in Section 11.1 looks like this: 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 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.

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 RFC8126 or RFC8126 policies. </del> <ins> Frame Type" registry operates under either of the "IETF Review" (RFC8126) or "IESG Approval" (RFC8126) policies. </ins> New entries in this registry require the following information:
Code change:
Followup for .
The code for the IANA policies in Section 11.1 looks like this: 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 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.

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 RFC8126. </del> <ins> Settings" registry operates under the "Expert Review" policy (RFC8126). </ins> New registrations are advised to provide the following information:
Code change:
Followup for .
The code for the IANA policies in Section 11.1 looks like this: 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 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.

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 RFC8126. </del> <ins> Error Code" registry operates under the "Expert Review" policy (RFC8126). </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new
Code change:
Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:

Related discussion:
text: PUSH_PROMISE frames. The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This <del> unsigned 31-bit integer indentifies 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 </del> <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 </ins> StreamCreation). PUSH_PROMISE frames MUST be associated with an existing stream.  If
Code change:
Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:

Related discussion:
text: The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the <del> receipient MUST respond with a StreamErrorHandler of type </del> <ins> recipient MUST respond with a StreamErrorHandler of type </ins> PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in
Code change:
Just state it. No need to justify it so (especially as this invites questions about the claimed benefits). This is less than Julian wanted from , but I think that it is important to include a requirement like this very clearly and it isn't really said anywhere else. At least not directly.
converted to lowercase when constructing an HTTP/2 message. I think this is somewhat misleading, it just provides the motivation why the lowercase format was introduced initially. I would just remove the sentence and potentially insert a note about lower-casing into the field name validity statements.
Agreed, I don't think the spec needs to defend itself on this choice.

Related discussion:
text: HTTP fields (HTTP) are conveyed by HTTP/2 in the HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with COMPRESSION. <del> To improve efficiency and interoperability, field names MUST be converted to lowercase when constructing an HTTP/2 message. </del> <ins> Field names MUST be converted to lowercase when constructing an HTTP/2 message. </ins> 8.2.1.
Code change:
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

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

Related discussion:
text: 11.7. <del> RFC7540 registered an upgrade token.  This capability has been removed: see versioning. </del> <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>
Code change:
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?

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

Related discussion:
text: not use TLS. Once TLS negotiation is complete, both the client and the server MUST <del> send a ConnectionHeader. </del> <ins> send a preface. </ins> 3.3.
Code change:
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.

Related discussion:
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> <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> <del> Likewise, the server MUST send a ConnectionHeader. </del> <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
Code change:
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.

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

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