jiebi/CodeConvo huggingface dataset:
Code change:
The HTTP fields defined in this document can be used for HTTP integrity.  Senders choose a hashing algorithm and calculate a digest <del> from an input related to the HTTP message, the algorithm identifier </del> <ins> from an input related to the HTTP message.  The algorithm identifier </ins> and digest are transmitted in an HTTP field.  Receivers can validate the digest for integrity purposes.  Hashing algorithms are registered <del> in the "Hash Algorithms for HTTP Digest Fields" (see algorithms). </del> <ins> in the "Hash Algorithms for HTTP Digest Fields" registry (see establish-hash-algorithm-registry). </ins> Selecting the data on which digests are calculated depends on the use <del> case of HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </del> <ins> case of the HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </ins> <del> There are use-cases where a simple digest of the HTTP content bytes </del> <ins> There are use cases where a simple digest of the HTTP content bytes </ins> is required.  The "Content-Digest" request and response header and trailer field is defined to support digests of content (RFC9110); see content-digest. <del> For more advanced use-cases, the "Repr-Digest" request and response </del> <ins> For more advanced use cases, the "Repr-Digest" request and response </ins> header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to selected representation data (RFC9110).  Basing "Repr-Digest" on the <del> selected representation makes it straightforward to apply it to use- </del> <ins> selected representation makes it straightforward to apply it to use </ins> cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass
Code change:
While input_string is not empty: <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If the first character of input_string is ")":

Related discussion:
text: An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.
Code change:
However, there are cases where relying on this alone is insufficient. An HTTP-level integrity mechanism that operates independent of transfer can be used to detect programming errors and/or corruption <del> of data at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del> <ins> of data in flight or at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document defines a mechanism that acts on HTTP representation- data.  It can be combined with other mechanisms that protect

Related discussion:
text: [x] avoid ambiguous statement on digest protecting from compressed content-coding URL i[x] t can protect from intermediaries altering representation metadata (content-type, content-coding)
Code change:
Section 5.4.1) of type PROTOCOL_ERROR. Endpoints MUST send this SETTINGS parameter as part of the first <del> SETTINGS frame.  When the peer receives the first SETTINGS frame, it learns the sender has deprecated the HTTP/2 priority scheme if it receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the value of 1. A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter value after the first SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del> <ins> SETTINGS frame.  A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter value after the first SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the priority signal defined in the HTTP/2 <del> priority scheme and also that of this prioritization scheme.  Once the client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </del> <ins> priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </ins> The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2 scheme before building state.  A server that receives <del> SETTINGS_DEPRECATE_HTTP2_PRIORITIES MUST ignore HTTP/2 priority signals. </del> <ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </ins> Where both endpoints disable HTTP/2 priorities, the client is expected to send this scheme's priority signal.  Handling of omitted

Related discussion:
text: Define deprecation of H2 priority as action, rather than defining it as a concept of "deprecation" then using that term to define the action. Probably resolves the first half of .
Merging this as an improvement, even if might have more to play out.
While I remain annoyed by the polarity of this setting for primarily aesthetic reasons, the PR is fine.
Code change:
. The <del> claim is used to express the type of the JSON object that is secured by the JWT.  The </del> value MUST be a case-sensitive <del> value. </del> <ins> value serving as an identifier for the type of the SD-JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims and associated rules (e.g., policies for issuing and validating credentials beyond what is defined in this specification). </ins> The following is a non-normative example of how is used to express a type: <ins> For example, a type can be defined such that at least the registered JWT claims , , , and must appear in the Unsecured Payload.  Additionally, the registered JWT claims and , and the private claims , , and may be used.  The type might also indicate that , , , can be selectively disclosable. </ins> 4.2.2.2. SD-JWT VCs MAY use any claim registered in the "JSON Web Token

Related discussion:
text: I worry about collisions and confusion with (and with ) - those of us that work with this stuff will likely understand the difference, but there is probably a better descriptor we could use than for this reason. Maybe specifying "schema" or "schemaName" or "sn" (for nice short form) would be more useful here
NAME there is a conversation on renaming type claim in Issue URL which should be a separate PR if we agree on an alternative claim name..
lgtm after we applied NAME suggestion
Code change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework RFC6749. </del> <ins> denotes the URL-safe base64 encoding without padding defined in Section 2 of RFC7515. </ins> 2. <ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the actor. Note: noneed to define anymore? </ins> 3. <del> In the following, the concept of SD-JWSs and matching proofs is described on a conceptual level. </del> <ins> In the following section, the concepts of SD-JWTs and releases are described at a conceptual level. </ins> 3.1. <del> An SD-JWS, at its core, is a signed document containing some metadata, the holder's public key, and hashed and salted claims.  It is signed using the issuer's private key. </del> <ins> An SD-JWS, at its core, is a digitally signed document containing hashes over the claim values with unique salts, optionally the holder's public key and other metadata.  It is digitally signed using the issuer's private key. </ins> <del> is usually a simple object with claim names mapped to salted and hashed claim values: </del> <ins> is usually a simple object with claim names mapped to hashes over the claim values with unique salts: </ins> can also be nested deeper to capture more complex objects, as will be shown later. <ins> The SD-JWT is sent from the issuer to the holder, together with the mapping of the plain-text claim values, the salt values, and potentially some other information. </ins> 3.2. <del> For a proof, a holder releases a document such as the following to the verifier: </del> <ins> To release to a verifier a subset of SD-JWT claim values, a holder creates a JWS such as the following: Note that the signature over is optional and required if, and only if, holder binding is desired. </ins> is usually a simple object with claim names mapped to values and salts:

Related discussion:
text: first pass, will cover other sections later
I approve of the content in this PR. (I would use the GitHub "Approve" function, but it appears that I may need write or contributor access to the repository to be able to do so. Could that be added for me?)
These changes are all worthwhile improvements.
Code change:
the Full Track Name in the Track ID field of the OBJECT (message- object) message headers of the requested track.  Track IDs are generally shorter than Full Track Names and thus reduce the <del> overhead in OBJECT messages. </del> <ins> overhead in OBJECT messages Subscribe ID: Subscription Identifer from the incoming subscription request for which this message is the response. </ins> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
The following content applies to the CWT Claims Set: <del> "1" (issuer): REQUIRED.  Same definition as "iss" claim in referenced-token-jwt. </del> <ins> "1" (issuer): REQUIRED when also present in the Referenced Token. Same definition as "iss" claim in referenced-token-jwt. </ins> "65535" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item

Related discussion:
text: Pretty straightforward fix for an oversight when relaxing the requirements for status list
The spec says: However, JWT defines as "REQUIRED if present in the reference token which means, the REQUIRED word is a bit misleading without the if-statement that follows. Either use OPTIONAL for , or also say in the CWT section.
Code change:
Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data <del> on a previous connection.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary. Finally, it is necessary to know whether the client will actually perform such a retry. </del> <ins> on a previous hop.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary.  Finally, it is necessary to know whether the client will actually perform such a retry. </ins> To meet these needs, two signalling mechanisms are defined:

Related discussion:
text: This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.
Code change:
. <ins> A server that supports range requests (range.requests) will usually attempt to satisfy all of the requested ranges, since sending less data will likely result in another client request for the remainder. However, a server might want to send only a subset of the data requested for reasons of its own, such as temporary unavailability, cache efficiency, load balancing, etc.  Since a 206 response is self- descriptive, the client can still understand a response that only partially satisfies its range request. A client MUST inspect a 206 response's and field(s) to determine what parts are enclosed and whether additional requests are needed. </ins> When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the subsections below, if the field would have been sent in a

Related discussion:
text: URL This seems to place a requirement on the server to serve enough of the representation that all satisfiable ranges requested are fulfilled. But that's actually a burden and makes range requests not as useful as they could be: a server might well not want to implement multipart/byteranges, which is an awkward format that can't be streamed without prior knowledge of what strings are safe to use as separators; responding with a single range is much simpler to implement. If all satisfiable ranges must be served, then, without multipart/byteranges, the only compliant options for responding to a range request with large distances between the requested ranges involve sending all of the bytes in between. Even reading the text as meaning that servers MUST NOT only serve a portion of the satisfiable ranges, client behaviour when faced with a misbehaving server is under-specified; the sensible options are re-requesting unfulfilled ranges, retrying without ranges, or signalling an error. Retrying without ranges may be wasteful, and raising an error seems overly fussy - and, if either of those is the better or even necessary option, that definitely ought to be called out. I'd be surprised if retrying without ranges or erroring was needed, because section 10.3.7.3 (Combining Parts) already deals with combining multiple 206 responses together. So, I think it'd make sense to make two changes here: An explicit SHOULD on clients receiving a 206 to check the ranges that they actually received and make further range requests if they still need any ranges which weren't included despite being satisfiable, which they can determine because Content-Range includes enough information to tell which were unsatisfiable and which were simply not fulfilled. Explicitly say that servers MAY only serve a portion of the satisfiable ranges.
It says "one or more" for exactly that reason. A requirement to send all would have to say ALL, so this is clearly not the case.
Wouldn't the text then be or something very similar? As presently written, I can't come up with a parse that unambiguously means that some of the satisfiable requested ranges may not be fulfilled - and, in any case, I do think the client behaviour on ranges not being fulfilled needs to be specced a bit more.
Code change:
. <ins> A server that supports range requests (range.requests) will usually attempt to satisfy all of the requested ranges, since sending less data will likely result in another client request for the remainder. However, a server might want to send only a subset of the data requested for reasons of its own, such as temporary unavailability, cache efficiency, load balancing, etc.  Since a 206 response is self- descriptive, the client can still understand a response that only partially satisfies its range request. A client MUST inspect a 206 response's and field(s) to determine what parts are enclosed and whether additional requests are needed. </ins> When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the subsections below, if the field would have been sent in a

Related discussion:
text: I read the current text as implying that in normal operation, the server will send all of the requested data back in some form; it might be in one range or multiple ranges, depending on its preferences and capabilities. NAME AIUI you want to rewrite this so that when a client sends (for example) requests for ranges 10-100, 500-1000 and 5000-6000, the server can just choose to send one (or two, in theory) of those ranges back, rather than all of them. That might be easier for the server in a number of ways, but it relies on the client recognising that the missing ranges need to be re-requested, one-by-one; effectively, it's a new protocol. As such, if you want to enable this new pattern, I think you'd need to signal support for it in some fashion from the client. That's out of scope for this spec effort; it would be an extension.
That is indeed what I'd like to have. I think there's definitely still room for at least clarifying the situation, given that two editors here read the text in two contradictory ways! Hmm, I don't quite agree. A well-behaved server would want to see support signalled before leaving some ranges unfulfilled and I agree that that would be a new protocol, but a malfunctioning or badly-behaved server might be ignoring the send-all-ranges requirement - I think that's especially likely to be happening in the wild given that the spec here is hard to interpret. Clients will still have to deal with that, and the spec can at least list reasonable options (re-request satisfiable-but-unfulfilled ranges, re-request the whole thing, error). Here's a new straw suggestion that (I think) doesn't change the required behaviours, just formalising and clarifying exactly what's required: An explicit MUST on servers returning enough of the representation to fulfil all satisfiable ranges. An explicit SHOULD on clients checking the Content-Ranges sent back, just in case a server is misbehaving, and list the three sensible options after detecting misbehaviour with MAY.
In normal operation, a server will try to send all of the requested information just for the sake of avoiding another request, unless it doesn't want to for its own reason that we have no need to describe. A 206 response is self-descriptive.
Code change:
. <ins> A server that supports range requests (range.requests) will usually attempt to satisfy all of the requested ranges, since sending less data will likely result in another client request for the remainder. However, a server might want to send only a subset of the data requested for reasons of its own, such as temporary unavailability, cache efficiency, load balancing, etc.  Since a 206 response is self- descriptive, the client can still understand a response that only partially satisfies its range request. A client MUST inspect a 206 response's and field(s) to determine what parts are enclosed and whether additional requests are needed. </ins> When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the subsections below, if the field would have been sent in a

Related discussion:
text: A client cannot interpret the response differently than how the response describes itself. The client cannot assume it has all the requested ranges it requested. There is no need to require that a server send all requested parts. There is no reason for a client to assume it would receive all of the parts without looking at the response. Hence, this is not subject to an interop requirement. The text I'd consider adding is a note at the end of that paragraph, like
Alternatively, just add that requirement to the section on 206.
I think the most compliant server response, if it doesn't support multipart/byteranges, is to respond with the range 10-6000. Servers are allowed to send different ranges than the client asked for, but I think a server omitting some of the requested ranges can't really claim to be "successfully fulfilling a range request." The server's response needs to include the bytes the client asked for. That said, I think something like NAME suggested text would be helpful. I've seen clients get tripped up before when the server produces a different set of requested ranges, either by extending a requested range or by coalescing ranges. It looks like a rewording of the text at the end of 10.3.7.2, which would be appropriate to either replicate in 10.3.7.1 (you can't expect exactly the range you requested) or move up to 10.3.7.