jiebi/CodeConvo huggingface dataset:
Code change:
request. An origin server that receives an If-Match header field MUST evaluate <del> the condition prior to performing the method (evaluation).  If the field value is "*", the condition is false if the origin server does not have a current representation for the target resource.  If the field value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag of the selected representation. </del> <ins> the condition prior to performing the method (evaluation). To evaluate a received If-Match header field: </ins> An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server

Related discussion:
text: URL This sentence describes cases where the selected representation exists and has an entity-tag. Shall we also specify that "if the selected representation does not exist or does not have an entity-tag, then the condition is false"?
Code change:
StreamPriority ensures that limited resources can be directed to the most important streams first. <del> HTTP/2 adds a new interaction mode whereby a server can PushResources.  Server push allows a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain.  The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame.  The server is then able to send a response to the synthetic request on a separate stream. </del> Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are FieldBlock. This has especially advantageous impact upon request sizes in the common case, allowing many requests to be compressed into one packet. <ins> Finally, HTTP/2 adds a new, optional interaction mode whereby a server can PushResources.  This is intended to allow a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain.  The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame.  The server is then able to send a response to the synthetic request on a separate stream. </ins> 2.1. The HTTP/2 specification is split into four parts:

Related discussion:
text: could have been a solution, but the work on it looks stopped.
URL
NAME suggested calling out the current status: lack of support in browser APIs for push, pointy edges in the usage, and the limitations in the spread of its usage. I think this is a reasonable editorial change.
NAME to draft a document to encourage users to set the value to 0 by default and move on.
Discussed at Feb 2021 interim; intent to document concerns / caveats, recommend sending setting = 0. NAME to PR.
LGTMVery nice. Thanks Mark.
Code change:
Let output be an empty string. <del> Append "*" to output. </del> <ins> Append ":" to output. </ins> Append the result of base64-encoding input_bytes as per RFC4648, Section 4, taking account of the requirements below. <del> Append "*" to output. </del> <ins> Append ":" to output. </ins> Return output.

Related discussion:
text: ... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The server MUST prevent that the offset exceeds the upload's final size when appending.  If a final size has been recorded and the upload append request exceeds this value, the server MUST stop appending bytes to the upload once the offset reaches the final size and reject the request with a "400 (Bad Request)" status code.  It is not sufficient to rely on the "Content-Length" header field for enforcement because the header field might not be present. </ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data.

Related discussion:
text: Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.
Code change:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The server MUST prevent that the offset exceeds the upload's final size when appending.  If a final size has been recorded and the upload append request exceeds this value, the server MUST stop appending bytes to the upload once the offset reaches the final size and reject the request with a "400 (Bad Request)" status code.  It is not sufficient to rely on the "Content-Length" header field for enforcement because the header field might not be present. </ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data.

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
transmission of software update files that would have the background urgency being associated.  However, in the worst case, the asymmetry between the precedence declared by multiple clients might cause <del> responses going to one end client to be delayed totally after those </del> <ins> responses going to one user agent to be delayed totally after those </ins> going to another. <del> In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the priority of "u=1, i" (i.e. round-robin) regardless of the value of the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients. </del> <ins> In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements. </ins> A server can determine if a request came from an intermediary through configuration, or by consulting if that request contains one of the

Related discussion:
text: cc NAME since it closes your issue.
I believe this is now good to go, please approve or speak up if you disagree.
In there is a rather firm recommendation to erase priorities at servers that are served by coalescing intermediaries: This seems wrong to me. The Priority header field provides information about what the User Agent thinks of priority. This might be adjusted by intermediaries on the path, and it might not be globally consistent, but that does not mean the information should be discarded. Instead, I would prefer that we say that when an intermediary coalesces requests from multiple clients, servers need to be aware of that and account for that in their processing. The remainder of this text is fine in the sense that it identifies information the server can use to more fairly allocate resources to different requests, but - again - this is just information the server uses when making prioritization decisions. The model we operate on should not assume be that Priority is an instruction to the server, but that it provides the server (or intermediary) clues about how it might decide to allocate resources.
No one responded to this for a while, sorry. The text is mostly untouched but I did change the example to just . My read of this today, I'm concerned that the requirement is a bit specific. It's not clear if a server applying this would also discard any additional priority parameters. I don't know if NAME original point was along those lines or not, but I'll try to make a PR to address what I think needs fixing
Code change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> BASE64URL denotes the URL-safe Base64 encoding without padding as defined in RFC7515, Section 2. </del> <ins> denotes the URL-safe base64 encoding without padding defined in Section 2 of RFC7515. </ins> 2.

Related discussion:
text: reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
Code change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> BASE64URL denotes the URL-safe Base64 encoding without padding as defined in RFC7515, Section 2. </del> <ins> denotes the URL-safe base64 encoding without padding defined in Section 2 of RFC7515. </ins> 2.

Related discussion:
text: We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.
Code change:
Common Name: Transaction Token <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document Section txn-token-request of this specification

Related discussion:
text: We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager
Code change:
expansion of the proxy's URI Template. If the request is well-formed and permissible, the proxy MUST attempt <del> the TCP connection before sending any response status code other than "100 (Continue)" (see conveying-metadata).  If the TCP connection is successful, the response SHALL be as follows: </del> <ins> to establish the TCP connection before sending any response status code other than "100 (Continue)" (see conveying-metadata).  If the TCP connection is successful, the response SHALL be as follows: </ins> The HTTP status code SHALL be "101 (Switching Protocols)".

Related discussion:
text: Changes: s/tcpport/targetport/ (aligning with connect-udp) Remove support for multiple IPs and
NAME The discussion at IETF 119 leaned toward removing the multiple-IP mode entirely. Are you suggesting that we should keep it?
This PR contains two changes; I'm not making a suggestion with regard to multiple-IP mode, but I think aligning the variable names in the template makes sense. Did both get dropped, or is that being discarded because it's in the same PR?
OK, I've updated this PR to also drop the multiple-IP support entirely.
The target_host variable is only described vaguely. It should be defined more rigorously. For example, it doesn't specify whether IPv6 scope IDs are allowed or not. I'd recommend reusing the text from RFC 9298.
OK, I've opened to make the definition more rigorous.
Fixed by
The draft currently defines the "targethost" and "tcpport" variables. We should replace "tcpport" with "targetport" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.
The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in , the client can use a single template for various purposes by inspecting the variables that it contains: "targetport" -> connect-udp "tcpport" -> connect-tcp "ipproto" -> connect-ip "dns" -> DoH Using the same name ("targetport") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori_ whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.
What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).
OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto").
Code change:
expansion of the proxy's URI Template. If the request is well-formed and permissible, the proxy MUST attempt <del> the TCP connection before sending any response status code other than "100 (Continue)" (see conveying-metadata).  If the TCP connection is successful, the response SHALL be as follows: </del> <ins> to establish the TCP connection before sending any response status code other than "100 (Continue)" (see conveying-metadata).  If the TCP connection is successful, the response SHALL be as follows: </ins> The HTTP status code SHALL be "101 (Switching Protocols)".

Related discussion:
text: It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119
Code change:
to wait before retrying the request.  In the absence of this header field, this document does not specify a minimum. <del> 2.1.1. </del> <ins> 3.1.1. </ins> <del> 2.1.1.1. </del> <ins> 3.1.1.1. </ins> Headers:

Related discussion:
text: A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM
Code change:
An empty List is denoted by not serializing the field at all.  This implies that fields defined as Lists have a default empty value. <del> When serialised as a textual HTTP field, each member is separated by </del> <ins> When serialized as a textual HTTP field, each member is separated by </ins> a comma and optional whitespace.  For example, a field whose value is defined as a List of Tokens could look like:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
G Grammar <del> ALPHA CR CRLF CTL </del> DIGIT <del> DQUOTE HEXDIG HTAB LF OCTET SP VCHAR </del> H Header Fields

Related discussion:
text: "The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.