jiebi/CodeConvo huggingface dataset:
Code change:
. The PRIORITY frame can be sent on a stream in any of the "reserved <del> (remote)", "open", "half closed (local)", or "half closed (remote)" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect.  For a stream that is in the "half closed (remote)" state, this frame can only affect processing of the stream and not frame transmission. </del> <ins> (remote)", "open", "half closed (local)", "half closed (remote)", or "closed" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream.  For a stream that is in the "half closed (remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. The PRIORITY frame is the only frame that can be sent for a closed stream.  This allows for the reprioritization of a group of dependent streams by altering the priority of the parent stream.  However, a PRIORITY frame sent on a closed stream risks being ignored due to the peer having discarded priority state information for that stream. </ins> 6.4.

Related discussion:
text: ... as new priority scheme demands and implies, but does not expressly permit. For .
Code change:
group.  The two proposals are listed in send-order and ordering-by- priorities.  We expect further work before a consensus is reached. <del> 3.2. TODO: Add text describing iteration of group and intra object priorities within a group and their relation to congestion response. Add how it refers to </del> 4. This document defines a protocol that can be used interchangeably

Related discussion:
text: NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.
Code change:
base by adding the "req" parameter to the component identifier. This parameter can be applied to both HTTP fields and derived <del> components with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message. </del> <ins> components that target the request, with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message instead of the target response message to which the signature is applied. </ins> Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same

Related discussion:
text: This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and
Code change:
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.6. </del> <ins> 2.4.6. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). <del> 2.4. </del> <ins> 2.5. </ins> The client uses the received authorization grant from steps B and C as an asseration towards authorization server of domain B. <del> 2.4.1. </del> <ins> 2.5.1. </ins> If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
Due to the operational challenge of maintaining a globally consistent append-only Log, some Transparency Services may provide limited <del> support for historical queries on the Transparent Statements they have registered, and accept the risk of being blamed for inconsistent </del> <ins> support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent </ins> Registration or Issuer equivocation. Verifier and Auditors may also witness (1,4) but may not be able to

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and

Related discussion:
text: I saw that too, but favoured compactness over avoiding parenthesis. Happy to take suggestions.
Try that.
briefly touches this topic. More explicit descriptions are helpful, such as: responses can be sent at any time, successful for failed ones responses may be completed before requests are completed. This is described for but should not be limited to 100-continue. for 2), should a client that sees a failure response continues sending the remaining request content?
3) is somewhat addressed in when the server also closes the connection
For (1) and (2), we could adjust to say (3) is situational. We could say something like 'A client that receives a response to its request while that request is still being sent SHOULD continue sending the request, unless some other signal indicates otherwise.' (with appropriate references, perhaps).
Okay, I have tweaked this editorially so that the paragraph makes sense, IMO.
Code change:
8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and

Related discussion:
text: ... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.
Code change:
8.3.3. <del> Media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) RFC2045.  However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see differences.between.http.and.mime). MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break.  HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.  An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.  In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively.  This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the content (e.g., header fields). If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded. 8.3.4. </del> MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body.  All multipart types share a common syntax, as defined in RFC2046, and

Related discussion:
text: implies a requirement: I would have said instead that HTTP itself doesn't care whether content adheres to this stricture, though some implementations could (or MAY) normalize line endings before sending or after receiving content that uses a media type.
Maybe we can improve the spec by just killing the whole subsection? It refers to the canonical form in MIME, then say we don't neef that, and then makes recommendations for text/* that AFAIU everbody ignores.
This was a huge deal back in 1995-96 and was necessary to bless deployed practice of sending native line endings and expecting the user agents to process them. I guess we can ignore that now? Don't be surprised if JK brings this up in IESG last call.Not seeing anything here worth saving.
Code change:
Holder about having received a complete set of Disclosures.  That is, for some digest values in the Issuer-signed JWT (which are not decoy digests) there may be no corresponding Disclosures, for example, if <del> the message from the Issuer was truncated. It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. </del> <ins> the message from the Issuer was truncated.  It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the user when needed. </ins> 7.2.

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
the response is produced, by enumerating the request header fields that it varies on, along with the values that are available for each. <del> Each "variant-item" indicates a request header field that carries a value that clients might proactively negotiate for; each parameter on it indicates a value for which there is an available representation on the origin server. </del> <ins> Variants is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be a list-of-lists (Section 3.3 of I-D.ietf-httpbis- header-structure) whose members are strings (Section 3.8 of I-D.ietf- httpbis-header-structure) or tokens (Section 3.9 of I-D.ietf-httpbis- header-structure).  Its ABNF is: If Structured Header parsing fails or a list-member has the wrong type, the client MUST treat the representation as having no Variants header field. The Variants header field represents an ordered list of "variant- axes", each of which consists of a request header "field-name" string and a list of "available-value" strings.  Each inner-list in the Variants header field value is parsed into a variant-axis.  The first list-member of the inner-list is interpreted as the field-name, and the remaining list-members are the available-values.  Any list-member that is a token (Section 3.9 of I-D.ietf-httpbis-header-structure) is interpreted as a string containing the same characters. Field-names in the Variants header field value MUST match the field- name production (Section 3.2 of RFC7230).  Clients receiving an invalid field-name MUST NOT match it to any content negotiating mechanism. </ins> So, given this example header field:

Related discussion:
text: I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?
Code change:
For instance, a speaker in a conferencing application might make a statement, and then ask, "but what do you folks think?"  If one of the listeners is able to answer in a timeframe that seems natural, <del> without without waiting for the current speaker to explicitly "hand over" control of the conversation, this would qualify as "Interactive". </del> <ins> without waiting for the current speaker to explicitly "hand over" control of the conversation, this would qualify as "Interactive". </ins> Live Streaming use cases allow consumers of media to "watch together", without having a sense that one consumer is experiencing

Related discussion:
text: NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"?
Code change:
For instance, a speaker in a conferencing application might make a statement, and then ask, "but what do you folks think?"  If one of the listeners is able to answer in a timeframe that seems natural, <del> without without waiting for the current speaker to explicitly "hand over" control of the conversation, this would qualify as "Interactive". </del> <ins> without waiting for the current speaker to explicitly "hand over" control of the conversation, this would qualify as "Interactive". </ins> Live Streaming use cases allow consumers of media to "watch together", without having a sense that one consumer is experiencing

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:
Code change:
9.1. <del> The W3C VCDM 2.0 (see TBD) defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations.  To interop with the W3C VCDM 2.0 data model defined in [TBD], this specification defines mapping algorithm for VC-SD-JWT and VP-SD-JWT to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD. </del> <ins> The W3C VCDM 2.0 VC-DATA defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations.  To interop with the W3C VCDM 2.0 data model defined in VC-DATA, this specification defines a mapping algorithm for VC-SD-JWT and VP-SD-JWT to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD. </ins> 9.1.1.

Related discussion:
text: I left some references open that will be addressed by other pull requests changing the surrounding text in order to avoid merge conflicts.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
lgtm
Code change:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend <del> server, requests that originate from one client might have higher precedence than those coming from others. </del> <ins> server, requests that originate from one client might carry priority signals indicating higher precedence than those coming from others. </ins> It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a

Related discussion:
text: Small editorial nit in relation to .
This looks ok but I still think we need a additional broader consideration of precedence to address the multiple comments about the term.