jiebi/CodeConvo huggingface dataset:
Code change:
value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. <ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer describing the number of bytes in the block.  The Chunk Length is encoded as a variable-length integer. Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field.  An Indeterminate-Length Field Section ends with a Content Terminator field.  The zero value of the Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 0. </ins> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format-

Related discussion:
text: I missed this from NAME but it's a point well-taken. Not defining this was sloppy.
This was buried inside which was closed so I'm opening a new issue. The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? It would really help if this draft defined every single field it declares.
The draft currently shows: This Length field isn't well defined. Is it the length of the Known-Length Field Section in bytes or in lines? If in bytes, does it include or exclude the length of the Length field itself? Either way, I don't understand why Length is at least 2. Either it's possible for there to not be any field lines, in which case maybe it should be zero. And if there needs to be at least one field line, then (we should say so, and) the minimum number should be 3, because a field line is two lengths and at least one byte of field name.
To pile on here, the spec also says in one place and in another It's a little ambiguous but f the value also can't be zero-length, then the minimum should be 4? (by David's second interpretation)
NAME see
Yeah saw that after hitting the button. Didn't intend to derail
Thanks
Code change:
3.3. <del> When attempting to extend priorities, care must be taken to ensure any use of existing parameters leaves them either unchanged or modified in a way that is backwards compatible for peers that are unaware of the extended meaning. </del> <ins> When attempting to define new parameters, care must be taken so that they do not adversely interfere with prioritization performed by existing endpoints or intermediaries that do not understand the newly defined parameter.  Since unknown parameters are ignored, new parameters should not change the interpretation of or modify the predefined parameters in a way that is not backwards compatible or fallback safe. </ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range

Related discussion:
text: Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.
Code change:
5.1. Proposals SHOULD be evaluated under a variety of bottleneck queue <del> disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. </del> <ins> disciplines.  The effect of an AQM discipline can be hard to detect by Internet evaluation.  At a minimum, a proposal should reason about an algorithm's response to various AQM disciplines.  Simulation or empirical results are, of course, valuable. </ins> Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this

Related discussion:
text: Suggested AQM text to address issue, when merge will
This section is listed as a special case, which it is (kind of), but it seems rather out of place in that section - I think we might wish to move it to the previous section. Since the original BCP, AQM is more common and really ought to be considered in any new design - even if the design does not wish to optimise for this.
Previously discussed in
Editors 1/16/24: Just add a sentence that AQMs are hard to detect, and therefore must be thought about -- cannot just ban use of a CC with AQM. But this falls thematically in with the special cases.
AQ are only a problem if they introduce unexpected behavior. The classic example is rate limiting, for which BB had to introduce special code.
Although packet scheduling and policing are useful complimentary functions, I don't think they are AQM.
Code change:
multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on. <ins> 3.8. The following example illustrates a typical HTTP/1.1 message exchange for a GET request (GET) on the URI "http://www.example.com/ hello.txt": Client request: Server response: </ins> 4. Uniform Resource Identifiers (URIs) RFC3986 are used throughout HTTP

Related discussion:
text: seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.
Code change:
offset is counted after the content's transfer coding is reversed but before the content coding is reversed. <del> 13. </del> <ins> 14. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.

Related discussion:
text: As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.
Code change:
2. <ins> 2.1. A JWT RFC7515 created by the issuer, which can be signed as a JWS RFC7515, that supports selective disclosure as defined in this document. 2.2. A JSON object created by the issuer that contains mapping between raw claim values that contained in the SD-JWT and the salts for each claim value. 2.3. A JWT created by the holder that contains a subset of the claim values of an SD-JWT in a verifiable way. 2.4. Ability of the holder to prove legitimate possession of SD-JWT by proving control over the same private key during the issuance and presentation.  SD-JWT signed by the issuer contains a public key or a reference to a public key that matches to the private key controlled by the holder. 2.5. An entity that creates SD-JWTs (2.1). 2.6. An entity that received SD-JWTs (2.1) from the issuer and has control over them. 2.7. An entity that entity that requests, checks and extracts the claims from SSD-JWT-R (2.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. <del> Note: noneed to define </del> <ins> Note: no need to define </ins> anymore?

Related discussion:
text: addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR
Code change:
client makes a refresh request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP <del> request entity-body: </del> <ins> request payload: </ins> REQUIRED.  Value MUST be set to "refresh_token".

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
the identifier's canonicalized value (described below). If Covered Content contains "*created" and the signature's Creation <del> Time is undefined or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. </del> <ins> Time is undefined an implementation MUST produce an error. </ins> If Covered Content contains "*expires" and the signature does not <del> have an Expiration Time or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. </del> <ins> have an Expiration Time an implementation MUST produce an error. </ins> If Covered Content contains an identifier for a header field that is not present or malformed in the message, the implementation MUST

Related discussion:
text: removes algorithm specific rules for content identifiers Current layout is not backward compatible with http-signatures, so it's safe to do it.
The rules that restrict when the signer can or must include certain identifiers appear to be related to the pseudo-revving of the Cavage draft that happened when the algorithm was introduced. We should drop these rules, as it can be expected that anyone implementing this draft will support all content identifiers.
Code change:
session as a 'Protocol Violation' if it receives a second bidirectional stream. <del> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a 'Protocol Violation'. </del> <ins> The control stream MUST NOT be closed at the underlying transport layer while the session is active.  Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.4.

Related discussion:
text: Sorry for the late response but I dont think this text is quite correct. If you're running MoQ over WebTransport, you're likely to be following the instructions in URL, which states My reading of the current text means that endpoints are likely to blend up treating things as a violation when there is no violation.
Section 3.3 says: "The control stream MUST NOT be abruptly closed at the underlying transport layer. Doing so results in the session being closed as a 'Protocol Violation'." I know we have multiple transports, but it would be good to clarify what an abrupt close is. Presumably any sort of RESET_STREAM, but what happens if there's a FIN? Is this a "clean close" of the session? Does it imply or force a reset of data streams?
LGTM
Code change:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.12. </del> <ins> 6.10. The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.11. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without

Related discussion:
text: This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.
Code change:
When a relay receives an incoming ANNOUCE for a given namespace, for each active upstream subscription that matches that namespace, it <del> SHOULD send a SUBSCRIBE to that publisher that send the ANNOUNCE. </del> <ins> SHOULD send a SUBSCRIBE to the publisher that sent the ANNOUNCE. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use

Related discussion:
text: As I was reading through the draft, I found some slight typos in the publisher interactions segment. This fixes them!
Code change:
2.5. <del> The signature base is a US-ASCII (STD80) string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </del> <ins> The signature base is a ASCII string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a

Related discussion:
text: Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.
Code change:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. <ins> While the proxy could additionally include the client's Signature value and Signature-Input fields from the original message in the new signature's covered components, this practice is NOT RECOMMENDED due to known weaknesses in signing signature values as discussed in security-sign-signature.  The proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server.  In this example, it is possible for the origin server to have additional information in its signature context to account for the change in authority, though this practice requires additional configuration and extra care as discussed in security-context- multiple-signatures.  In other applications, the origin server will not be able to verify the original signature itself but will still want to verify that the proxy has done the appropriate validation of the client's signature.  An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely. </ins> 5. While a signer is free to attach a signature to a request or response

Related discussion:
text: Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.
Code change:
Security considerations in this section help achieve the following properties: <ins> An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT. A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in holder_binding_security, the application of Holder Binding can ensure that the presenter of an SD- JWT credential is the legitimate Holder of the credential. </ins> 8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the

Related discussion:
text: This fixes Issue . The main change is to better describe in which role the adversary acts.
does this one need a doc history entry... ?
Code change:
Security considerations in this section help achieve the following properties: <ins> An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT. A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in holder_binding_security, the application of Holder Binding can ensure that the presenter of an SD- JWT credential is the legitimate Holder of the credential. </ins> 8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the

Related discussion:
text: Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm
Code change:
3.3. A client can learn that a particular server supports HTTP/2 by other <del> means.  For example, ALT-SVC describes a mechanism for advertising this capability. A client MUST send the ConnectionHeader and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del> <ins> means.  For example, a client could be configured with knowledge that a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.

Related discussion:
text: As stated in , it's misleading and contradictory. Better to concentrate on configuration for this, as that is the common usage.
Section 3.3 says the following about cleartext HTTP/2: I had previously conceived of Alt-Svc as requiring a certificate and TLS, but that's not strictly true. RFC 7838 says that a client MUST have reasonable assurances, and a TLS cert is one way to do that. It also says that the connection must have equal or better security properties, which implies you can't go from TLS to non-TLS. This statement suggests that it's valid to offer on an http:// URI if your server can accept direct-to-H2 connections, but doesn't explicitly say so. Is that the intended reading here? But RFC 7838 says: Perhaps that doesn't apply, because the alternative is the same server on the same TCP port. Still, I feel like this waves at Alt-Svc for a use which is, at best, under-specified; at worst, not actually possible.