jiebi/CodeConvo huggingface dataset:
Code change:
bandwidth-delay product (see RFC7323). Even with full awareness of the current bandwidth-delay product, <del> implementation of flow control can be difficult.  When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion.  Failure to do so could lead to a deadlock when </del> <ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when </ins> critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> Reading frames promptly does not expose endpoints to resource exhaustion attacks as HTTP/2 flow control limits resource commitments. </ins> 5.2.3.

Related discussion:
text: ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13. ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Code change:
bandwidth-delay product (see RFC7323). Even with full awareness of the current bandwidth-delay product, <del> implementation of flow control can be difficult.  When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion.  Failure to do so could lead to a deadlock when </del> <ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when </ins> critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> Reading frames promptly does not expose endpoints to resource exhaustion attacks as HTTP/2 flow control limits resource commitments. </ins> 5.2.3.

Related discussion:
text: This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other? In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Yeah, good rewording here.
Code change:
reflect the message received, excluding some fields described below, back to the client as the content of a <del> response with a of "message/http" (media.type.message.http).  The final recipient is either the origin server or the first server to receive a </del> <ins> response.  The "message/http" (media.type.message.http) format is one way to do so.  The final recipient is either the origin server or the first server to receive a </ins> value of zero (0) in the request (field.max-forwards).

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
Type Metadata for the type can be retrieved using various mechanisms as described in retrieving- <del> type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL </del> <ins> type-metadata.  For this example, the </ins> <del> : </del> <ins> value is a URL as defined in retrieval-from-vct-claim and the following Type Metadata Document is retrieved from it: </ins> This example is shortened for presentation, a full Type Metadata example can be found in ExampleTypeMetadata.

Related discussion:
text: Remove the requirement to insert a .well-known part for vct URLs , ,
Dr. Fett, PhD: >Gentlemen, Some feedback I received (on top of the comments we already got in the issuers) makes me second-guess the choice to use a .well-known URL for the type metadata documents. In fact, RFC 5785 tells us that .well-known is mainly to be used for site-wide information or information about a specific host. that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. Brian Campbell, B.A.: >That feedback seems not wrong to me. We've got probably a lot of somewhat questionable uses of .well-known but type metadata is maybe less well suited than most. And less needed. >It could just point to the json document. Or we make up some convention. Or something with uri templates.
Relevant related issues: , ,
I believe that lifting the restriction is not preventing the use of .well-known; IMO there are two approaches provide the full link signal that the metadata is under the well-known However, metadata owner must be aware of the responsibility to take care of the versioning. As mentioned in , should there be a requirement to either use hash links or protect the remote content via vct#digest? Dr. Horvat, PhD
Maybe I'm missing something, but the change in PR should mostly solve this, I think. It now requires to provide the full URL to the metadata. (If someone wants to provide it under .well-known, that is their choice, but doesn't influence the requester at all). For versioning I filed a . Not sure about making #digest mandatory, but we should also discuss this separately.
digest mandatory, but we should also discuss this separately. -> if it's an external resource, it should be defined how it is protected
URL Is defining that if vct is an https:// it should check the metadata under the well known (at least the 2nd part of the text reads like this: Many registries are, and will be accessible via URLs, hence the metadata type is expressed via an URL; Adding or maintaining a .well-known might not fit in the existing API designs.
Code change:
Type Metadata for the type can be retrieved using various mechanisms as described in retrieving- <del> type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL </del> <ins> type-metadata.  For this example, the </ins> <del> : </del> <ins> value is a URL as defined in retrieval-from-vct-claim and the following Type Metadata Document is retrieved from it: </ins> This example is shortened for presentation, a full Type Metadata example can be found in ExampleTypeMetadata.

Related discussion:
text: Also note that .well-known has well-known issues with multi-tenancy. Most use cases will delegate the hosting of the information to registries. Also Questions: if schema is https, should the full URL be provided? (no ambiguity with .well-known, you can host schema on github, ...) metadata retrieval category re-consideration: 1) Fetch vct from a remote source: a) URL: HTTPS schema -> full URL that points to a schema b) URN: domain-defined URN that MUST be understood by the wallet; The URN method defines how to map the URN to URL and retrieve the data 2) Fetch vct the metadata locally a) local cache b) Signature (signed or unsigned header); Whether or not metadata is shared in the (un)protected header is defined by the signature format, hence out of scope of this document. 2b: point to consider for the OID4VP: should there be a flag: "archival mode" or similar, that would flag that the wallet needs to provide all the referenced content in an unprotected JWS header?
removes the requirement to insert .well-known (discussion in )
Type Metadata introduced new well-known URI /.well-known/vct/ in "6.3.1. From a URL in the vct" , but this is not reflected in appendix-A.3 Well-Known URI Registry. Additionally, using in sentence "Metadata can be retrieved from the URL URL, i.e., by inserting /.well-known/vct after the authority part of the URL." seems to me a little bit confusing as type is considered to refer to whole URI. Maybe use or (to include also query and fragment URI components)?
Thank you and yes, the registration request is missing and needs to be added. And that sentence could also be improved.
Although the use of .well-known for type metadata is being reconsidered
Current text: Since well-known only applies to HTTPS URLs, we should limit the section to HTTPS URLs although other URLs would be still possible, e.g., . Additionally, also the in is probably not correct since the type refers to the value itself which would not make sense to the full value here which would also include the scheme for instance. I suggest we update the title to "From an HTTPS URL in the claim" and update the language to something like this:
Code change:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> Field Value MUST be treated as a connection error.  In HTTP/2 the error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type H3_FRAME_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open.  Furthermore, HTTP/3 offers no guaranteed

Related discussion:
text: NAME correctly pointed out that the draft contained a made up error code. On inspection, we need to define specific error codes for both H2 and H3. This change does that.
The latest version of the draft states: There is no such error either in or in . Perhaps HTTP/3's H3FRAMEERROR was meant?
Dang, I worked from memory and should've spent 2 minutes for checking. I'll get this fixed up thanks.
Code change:
The "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and target URI, might influence the origin server's process for selecting and <del> representing this response.  The value consists of either a single asterisk ("*") or a list of header field names (case-insensitive). A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate a Vary field with a "*" value. A Vary field value consisting of a list of field names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </del> <ins> representing this response. A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the representation for this response.  Potential selecting header fields are not limited to those defined by this specification. If the list contains "*", it signals that other aspects of the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </ins> For example, a response that contains

Related discussion:
text: Leaves registration of "" for .
Yes, seems to be a bug in bap. Will check.
it uses "" / #vary but "vary" is a token, and token allows "" anyway. Also, see .
In particular, "" is a valid field name. We probably should reserve it in the registry.
(CORS has an issue like that as well, including for a method; see the note at URL)
Proposal: vary-by = "" / field-name Vary = 1#vary-by Then state that if "" appears, no "real" field-name is allowed to appear as well (for backwards compat). Do we need to discuss cases like Vary: , ?
I don't see why that is an improvement.
I thought we were going to reserve and define its meaning in prose...
I.e., it should just be
which implies registering "*" as reserved field name, right?
Yes. That's
Discussed; will create a PR to move ABNF and prose to list-based.
Do we need to list that as change from 7230?
Probably a good idea; will commit to master and link here.
hit the wrong option
Code change:
is the actual Holder of the license.  The Verifier (e.g., the software used by the police officer) will ensure that a Holder Binding JWT is present and signed with the Holder's private key. <ins> Claims-based Holder Binding may be used as well, e.g., by including a first name, last name and a date of birth that matches that of an insurance policy paper. </ins> A rental car agency may want to ensure, for insurance purposes, that all drivers named on the rental contract own a government-issued

Related discussion:
text: As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity
Code change:
field safe for processing by waiting for the handshake to complete. A request that is marked with Early-Data was sent in early data on a previous hop.  Requests that contain the Early-Data field and cannot <del> be safely processed MUST be rejected using the 4NN (Too Early) status </del> <ins> be safely processed MUST be rejected using the 425 (Too Early) status </ins> code. 5.2. <del> A 4NN (Too Early) status code indicates that the server is unwilling </del> <ins> A 425 (Too Early) status code indicates that the server is unwilling </ins> to risk processing a request that might be replayed. Clients (user-agents and intermediaries) that sent the request in <del> early data MUST automatically retry the request when receiving a 4NN </del> <ins> early data MUST automatically retry the request when receiving a 425 </ins> (Too Early) response status code.  Such retries MUST NOT be sent in early data. <del> Intermediaries that receive a 4NN (Too Early) status code MAY </del> <ins> Intermediaries that receive a 425 (Too Early) status code MAY </ins> automatically retry requests after allowing the handshake to complete unless the original request contained the "Early-Data" header field when it was received.  Otherwise, an intermediary MUST forward the <del> 4NN (Too Early) status code. </del> <ins> 425 (Too Early) status code. </ins> The server cannot assume that a client is able to retry a request unless the request is received in early data or the "Early-Data" <del> header field is set to "1".  A server SHOULD NOT emit the 4NN status </del> <ins> header field is set to "1".  A server SHOULD NOT emit the 425 status </ins> code unless one of these conditions is met. <del> The 4NN (Too Early) status code is not cacheable by default.  Its </del> <ins> The 425 (Too Early) status code is not cacheable by default.  Its </ins> payload is not the representation of any identified resource. 6.

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
This type helps distinguish between responses generated by intermediaries from those generated by the origin. <del> 2.3.29. </del> <ins> 2.3.25. </ins> Name: http_request_denied

Related discussion:
text: PTAL NAME NAME NAME
Looks reasonable to me!
NAME PTAL; I'll merge tomorrow if I don't hear anything.
NAME how do you distinguish between a proxy certificate and the certificate used for the next hop?
By "proxy certificate" I mean the certificate sent by the CDN (when acting as a client) to the origin server for the purpose of mutual authentication. In contrast, would apply (at least in my mind) only to the certificate presented by the origin server.
So, I think the argument is that is either a (i.e., the server you're connecting to gave you an error to the effect that you need to present a client certificate), or a (i.e., you realised you need to present a certificate before connecting, but don't have one) depending on exactly how the error occurred. Is that sufficient?
As someone who spent countless hours debugging connection issues to various origin servers, my main concern is that alone doesn't provide enough information as to why the connection failed, it only narrows it down to a TLS certificate issue, but for anything definitive that you would want to share with the customer, you'd still need to go and dig further into logs, or try to replicate the issue. Yes, I know that you could put more information in the "details" field, but I'm not a big fan of implementation-specific free-form text. Having said that, I'm not going to oppose if you prefer to have only those 3 generic fields.
Thanks. As Ryan points out, the problem is that implementations have different terminology and granularity of error reporting, and it's not the place of this specification to impose that on them.
Looking at what to map x509 errors (as returned by into, the most obvious one is . However, there's also , which is one of these errors. It seems odd to have these two, but not any of the many other verification errors. At first glance, I suspect it may be better to have a single error, and let the convey the reason - whether it's expiration or something else.
Ultimately, there is a fine balance between providing a generic "catch-all" error, and enumerating all possible errors. The linked lists 69 possible reasons for success or failure, and including all of them clearly doesn't make sense, especially when only a few of them will happen in practice.