jiebi/CodeConvo huggingface dataset:
Code change:
For example, a fictitious Foo-Example header field might be specified as: <ins> Note that because the definition of a Structured Field references a specific RFC for Structured Fields, the types available for use in its value are limited to those defined in that RFC.  For example, a field whose definition references this document can have a value that uses the Date type (date), whereas a field whose definition references RFC 8941 cannot, because it will be treated as invalid (and therefore discarded) by implementations of that specification. Also note that this limitation also applies to future extensions to a field; for example, a field that is defined with reference to RFC 8941 cannot use the Date type, because some recipients might still be using an RFC 8941 parser to process it. However, this document is designed to be backwards-compatible with RFC 8941; a parser that implements the requirements here can also parse valid Structured Fields whose definitions reference RFC 8941. The effect of upgrading a Structured Fields implementation is that some field values that were invalid according to RFC 8941 might become valid when processed.  For instance, though it would not be valid for a field defined against RFC 8941, a field might include include a Date value.  An RFC 8941 implementation would reject the entire field, whereas an updated Structured Field implementation might permit the value.  In some cases, the resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not be detected and the field might subsequently be accepted and processed. </ins> 3. This section defines the abstract types for Structured Fields, and

Related discussion:
text: That means that rejection by a receiver isn't guaranteed, but it offers a path toward upgrade at some point (we could decide, collectively, that it is OK to use sf-date in an extension for an older field definition. We might do that based on adoption rates for the new SF version, and memorialize it with an update to the field, but we wouldn't necessarily need to pick a new field name in order to avoid the compatibility risk (we'd just be managing the probability of it happening).
It would be interesting to see more feedback from people defining APIs for SF support...
How does the PR imply that?
Well, if a spec refers to an SF-shaped field based on RFC 8941, parsing it with an 8941bis parser (allowing sf-date) would be incorrect. RFC 8941 requires draconian error handling, after all. When we defined RFC 8941, we consciously specced draconian error handling + no extension points (until the spec is updated), so that's the consequence. I fear that we are in a very fundamental disagreement about how extending the structured field syntax is supposed to happen given the constraints we put into 8941.
Perhaps it would be best to take this to the list. I don't see anyone else who yet shares your point of view, so it would be good to circulate it with a wider audience.
(with two nits)
Code change:
The details of this kind of profiling are the purview of the application and outside the scope of this specification, however some <del> additional considerations are discussed in security. </del> <ins> additional considerations are discussed in security.  In particular, when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in security-coverage and security-message- content. </ins> 2.

Related discussion:
text: Adds a citation in 1.4 for DIGEST and forward links to the security considerations sections for covered component selection and message body coverage.
Minor issue noted while reviewing. -13 does give a good overview of message content considerations, and mentions Content-Digest along with a citation to the digest headers draft. However, the earliest mention of Content-Digest is in section 1.4, and there are several examples through the text that use it. Simple fixup is to cite digest in section 1.4 too, and forward ref to 7.2.8 so anyone interested in this knows where to jump to.
Code change:
2.3. <del> A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the parameter "prefix" with the value of N as an integer. A list prefix value is canonicalized by applying the serialization algorithm described in RFC8941 on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List. 2.3.1. This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries: The following table shows example canonicalized values for different content identifiers, given those fields: 2.4. </del> Content not found in an HTTP header can be included in the signature base string by defining a content identifier and the canonicalization method for its content.

Related discussion:
text: Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?
Code change:
3.3. The first stream opened is a client-initiated bidirectional control <del> stream where the peers exchange Setup messages (message-setup).  All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del> <ins> stream where the endpoints exchange Setup messages (message-setup). All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no

Related discussion:
text: Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.
Code change:
10.2.2. <del> The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in RFC5322.  The field value is an HTTP-date, as defined in http.date. An example is A sender that generates a Date header field SHOULD generate its field value as the best available approximation of the date and time of message generation.  In theory, the date ought to represent the moment just before generating the message content.  In practice, a sender can generate the date value at any time during message origination. An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instant in Coordinated Universal Time.  An origin server MAY send a Date header field if the response is in the or class of status codes.  An origin server MUST send a Date header field in all other cases. A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream. A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks. 10.2.3. </del> The "Location" header field is used in some responses to refer to a specific resource in relation to the response.  The type of relationship is defined by the combination of request method and

Related discussion:
text: This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho
Code change:
fields by responding with a "400 (Bad Request)" status code. If the server considers the upload resource to be active, it MUST <del> respond with a "204 (No Content)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </del> <ins> respond with a "204 (No Content)" or "200 (OK)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource. The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </ins> An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-

Related discussion:
text: A server might allow GET requests to be sent to an upload resource and serve content, in which case a 200 status code is more appropriate for responses to HEAD requests. This PR lifts the requirement that a successful response must be a 200.
The current draft requires the server to respond with a 204 No Content status code for HEAD requests: [...] If the server considers the upload resource to be active, it MUST respond with a 204 (No Content) status code. This restriction is too strict and does not allow the server to respond with a 200 OK. Since the HEAD requests for resumable uploads do not include any specific additional header field, the server cannot tell apart whether a HEAD request is used for resumable uploads or used for starting a download, for example. For example, a server might allow to download the uploaded file through a GET request to the upload URL. HEAD requests to this URL should then return the same status code (e.g. 200) and header fields as the GET request would do. But the draft requires a server to always respond with 204, leading to a conflict. Can we also allow 200 for HEAD responses?
I think this would be a good change to the spec. Maybe use similar language as with PATCH, where we allow the entire 2xx range but have a recommended status code? I don't think this would be an issue for any client. Is this a typo? Should be "... 200 for HEAD..."? >Can we also allow 204 for HEAD responses?
That's correct. Thank you for pointing out
Code change:
frame.  SettingsSync is not necessary, since a 101 response serves as implicit acknowledgment.  Providing these values in the Upgrade <del> request ensures that the protocol does not require default values for the above SETTINGS parameters, and gives a client an opportunity to provide other parameters prior to receiving any frames from the server. </del> <ins> request gives a client an opportunity to provide parameters prior to receiving any frames from the server. </ins> 3.3. <del> A client that makes a request to an "https" URI without prior knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </del> <ins> A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.

Related discussion:
text: A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.
Code change:
A conditional request is an HTTP request with one or more request header fields that indicate a precondition to be tested before applying the request method to the target resource.  evaluation <del> defines when preconditions are applied.  precedence defines the order of evaluation when more than one precondition is present. </del> <ins> defines when to evaluate preconditions and their order of precedence when more than one precondition is present. </ins> Conditional GET requests are the most efficient mechanism for HTTP cache updates Caching.  Conditionals can also be applied to state-

Related discussion:
text: They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Code change:
A conditional request is an HTTP request with one or more request header fields that indicate a precondition to be tested before applying the request method to the target resource.  evaluation <del> defines when preconditions are applied.  precedence defines the order of evaluation when more than one precondition is present. </del> <ins> defines when to evaluate preconditions and their order of precedence when more than one precondition is present. </ins> Conditional GET requests are the most efficient mechanism for HTTP cache updates Caching.  Conditionals can also be applied to state-

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)
Code change:
current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <del> Likewise, either party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </del> <ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </ins> 2.3.

Related discussion:
text: Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.
Code change:
4.2. <del> These criteria evaluate the interaction of the proposed congestion control algorithm with commonly deployed congestion control algorithms. </del> <ins> Mixed algorithm behavior criteria evaluate the interaction of the proposed congestion control algorithm with commonly deployed congestion control algorithms. </ins> In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
This would result in the following unsigned response message: <del> The server signs the response with its own key and includes the signature of "sig1" from the request in the covered components of the response.  The signature input string for this example is: </del> <ins> To cryptographically link the response to the request, the server signs the response with its own key and includes the signature of "sig1" from the request in the covered components of the response. The signature input string for this example is: </ins> The signed response message is:

Related discussion:
text: update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples
Code change:
zero or more <del> frames containing the message payload (see RFC7230), and </del> <ins> frames containing the payload body (see RFC7230), and </ins> optionally, one

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.