jiebi/CodeConvo huggingface dataset:
Code change:
8.8.4. <del> A response that includes control data and a response header and </del> <ins> A response that includes control data and a response header with </ins> message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag

Related discussion:
text: This is awkward, but this is better.
and 8.8.4: Because "control data and a request header and message content" reads a bit oddly, we changed it to "control data and a request header with message content" per "control data and a request header with no message content" in Please let us know if this is incorrect. Original: An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set: Currently: An HTTP POST request that includes control data and a request header with message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header with message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set:
Code change:
case, the mechanisms defined in this document can be used for many other use cases as well. <del> Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general mechanism of selective disclosure defined here. </del> <ins> This document also describes holder binding, or the concept of binding SD-JWT to a key material controlled by the subject of SD-JWT, which is optional to implement. </ins> 1.1.

Related discussion:
text: Issue and . Describing the concept of holder binding and giving minimum directions on: find pubKey in SD-JWT Sign SD-JWT-R using privKey bound to a pubKey in SD-JWT but leaving details to the profiles and implementations.
Code change:
problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). <del> Note that the field name "Close" is reserved, since using that name as an HTTP header field might conflict with the "close" connection defined above. </del> See compatibility.with.http.1.0.persistent.connections for more information on backwards compatibility with HTTP/1.0 clients.

Related discussion:
text: The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).
Code change:
ends of the connections do not accept SACK), then this algorithm can be extended to estimate approximate delivery rates using duplicate ACKs (much like Reno and RFC5681 estimates that each duplicate ACK <del> indicates that a data packet has been delivered).  The details of this extension will be described in a future version of this draft. </del> <ins> indicates that a data packet has been delivered). </ins> 4.5.3.

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
in path characteristics on the interval of common Internet re-routing intervals. <del> 7.8. </del> <ins> 7.10. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Related discussion:
text: From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.
Code change:
status code indicates that the has been assigned a new permanent URI and any future references to <del> this resource ought to use one of the enclosed URIs.  Clients with link-editing capabilities ought to automatically re-link references to the target URI to one or more of the new references sent by the server, where possible. </del> <ins> this resource ought to use one of the enclosed URIs.  The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited. </ins> The server SHOULD generate a

Related discussion:
text: The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.
Code change:
. <ins> A field present in a 206 response indicates the number of octets in the body of this message, which is usually not the complete length of the selected representation.  Each field includes information about the selected representation's complete length. </ins> If a 206 is generated in response to a request with an header field, the sender SHOULD NOT generate other representation

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
The "no-cache" response directive indicates that the response MUST <del> NOT be used to satisfy a subsequent request without successful validation on the origin server.  This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </del> <ins> NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </ins> If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request,

Related discussion:
text: The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.
Code change:
compliant implementation. Remove any obsolete line-folding within the line and replace it <del> with a single space (""), as discussed in MESSAGING.  Note that </del> <ins> with a single space (" "), as discussed in MESSAGING.  Note that </ins> this behavior is specific to MESSAGING and does not apply to other versions of the HTTP specification. Concatenate the list of values together with a single comma (",") <del> and a single space ("") between each item. </del> <ins> and a single space (" ") between each item. </ins> The resulting string is the canonicalized component value.

Related discussion:
text: Includes several document cleanups for signatures, to publish as -09
Also: If there is no query string should the corresponding signing text be or ie. should the query value be empty or just consist of one Should we return with this request and return on this request This is what I opted for in my implementation. See shows that http4s makes the distinction between blank queries and empty queries is simpler I think this is a corner case that is worth explicating very clearly, perhaps even with a test.
There are quite a few occurrences of the header in the draft. From an implementation point of view, Go "swallows" the header and it is not part of the standard Request structure. There's a good reason for the Go library to do it, and in fact the draft recommends to use NAME instead. Can we remove from examples, e.g. Sec. 2.1, so we don't train people to do the wrong thing?
There are only a couple instances of the "host" header in the current draft left, and one of them (section 2.1) is specifically about how to format headers. It could be removed from the other example signature input strings without affecting anything negatively. Same with the "date" header, which could be confused with the "created" parameter, see
This sentence is correct: But it's true for most reasonable uses of , and people will still be using this parameter. So why not add:
No, we explicitly did not want to conflate this with the jwa registry. We also didn't want to have a second tier choice like having "alg=jose" and then having the actual algorithm elsewhere, since a big problem with late editions of the Cavage draft were exactly that process. (See the mess around "hs2019"). The editors discussed this at length and decided the best compromise was to define a way that jwa algorithms could be used in an interoperable fashion, but not to allow runtime signaling with them. Better to have the choice of jwa be signaled within the application level. Additionally, it's preferable to not use the runtime parameter to signal the algorithm any way, which is discussed at length in the security considerations.
All good, so why aren't you using normative language?
It's not normative because this section defines the algorithms, not the parameter.
Code change:
compliant implementation. Remove any obsolete line-folding within the line and replace it <del> with a single space (""), as discussed in MESSAGING.  Note that </del> <ins> with a single space (" "), as discussed in MESSAGING.  Note that </ins> this behavior is specific to MESSAGING and does not apply to other versions of the HTTP specification. Concatenate the list of values together with a single comma (",") <del> and a single space ("") between each item. </del> <ins> and a single space (" ") between each item. </ins> The resulting string is the canonicalized component value.

Related discussion:
text: We didn't want to make it seem like the parameter was the "right" way to signal algorithms here, and most certainly is not required. You'll notice that none of the other sections have "MUST use the alg parameter value of 'foo'" either. Older Cavage drafts relied on the parameter, albeit in a much less secure fashion, and implementations were susceptible to algorithm substitution in the same way that naive JOSE implementations tend to be -- the "alg: none" attack all over again, more or less. The value of the parameter already MUST be something from the registry, and the registry does not (and will not) contain JWA values. So you already aren't allowed to do it, normatively, and the note is our attempt at explaining the why. Ultimately, an implementation is allowed to use whatever algorithm they want and makes sense. What this whole section does is define a set of common usable algorithms as well as provide a pattern of applying crypto primitives that applications can follow for their own algorithms. If someone defines a new algorithm that's generally useful, like we recently did with the ed25519 here, it can be registered for use with the parameter. But if a system can base the algorithm selection off of the key material or another part of the protocol (like with GNAP), that's highly preferable and less vulnerable to substitution at runtime. I'd be happy to know how we can make this clearer in the text, but I'm not comfortable with that kind of normative construct in that section.
NAME -- would you like to chime in? I recall from our discussions you having another, more specific reason for this decision, but I can't remember the details beyond us agreeing to do it the way we have it in the spec right now.
Neither Java nor JS subtleCrypto come out of the box with PKCS1 PEM support. (for java ). It is not immediately obvious to work out that the PEM formats of the private key in in PKCS1 format (the spec could point that out). When building an implementation it helps to have the test suite clearly map to the data in the spec (e.g. ) so as to make error reporting clearer. That is even though using the following openssl command to convert the keys work, it makes it difficult to see if an error was introduced at some point.
Code change:
compliant implementation. Remove any obsolete line-folding within the line and replace it <del> with a single space (""), as discussed in MESSAGING.  Note that </del> <ins> with a single space (" "), as discussed in MESSAGING.  Note that </ins> this behavior is specific to MESSAGING and does not apply to other versions of the HTTP specification. Concatenate the list of values together with a single comma (",") <del> and a single space ("") between each item. </del> <ins> and a single space (" ") between each item. </ins> The resulting string is the canonicalized component value.

Related discussion:
text: To support PKCS1 the developer has to depend on further less well tested libraries and add additional code (as I ) leading possibly to new bugs. Furthermore, I will need to go through the same process for JavaScript now, doubling the work. Since PKCS8 is as expressive as PKCS1 ( and see ), it would make life easier for devs if the keys were all in PKCS8 format. Unless there really is something that PKCS1 offers that PKCS8 does not? I will try doing this using the Web Crypto API next. But there we find that supports the PKCS format.
While I am at it. I am having trouble with verifying the signature for 3 out of 4 examples from the spec that I tried out in . Currently the only one that works is the . I am able to produce and verify a signature for , and examples, but the signatures don't correspond to what is in the spec. That may very well be a mistake in my code, which I am working on as a to bobcats scala and scala-js crypto library. But I just wanted to check how confident you were in your examples. I am going to re-implement next in JS, so that will give me another reference point.
I am working my way through this with JS. I was able to parse the and keys after translating them to pkcs8 format with openssl, but am having trouble importing in the console of Chrome, Chrome-beta, Chrome-Dev and Safari. I guess that is in pkcs8 format already. I don't have trouble parsing that key with BouncyCastle... I guess this is a little config problem, but it's difficult to work out what that could be... Perhaps someone has an idea?
NAME Since this all has to do with the examples in the text and not the spec itself, I think we'd be fine with having the keys in multiple formats if it's useful for developers. However I'll note that in many code libraries you need to add the PEM headers of and for their compliant parsers to parse an EC key in PEM format, for example. I've been able to parse these keys in both Java and Python, and in fact all the examples are generated using a python script: URL Also, note that RSA-PSS and ECDSA are non-deterministic signatures that incorporate a source of randomness into the signature calculation.
Code change:
compliant implementation. Remove any obsolete line-folding within the line and replace it <del> with a single space (""), as discussed in MESSAGING.  Note that </del> <ins> with a single space (" "), as discussed in MESSAGING.  Note that </ins> this behavior is specific to MESSAGING and does not apply to other versions of the HTTP specification. Concatenate the list of values together with a single comma (",") <del> and a single space ("") between each item. </del> <ins> and a single space (" ") between each item. </ins> The resulting string is the canonicalized component value.

Related discussion:
text: This might be why you're getting valid signatures that look different from the examples -- you shouldn't expect to replicate the exact signature values. RSA 1.5 is deterministic, and will always give this same signature for the same input (as will HMAC). This is just one of the reasons why it's not recommended in many environments. I think we can add some text in the examples sections that points this out, if that would be helpful.
NAME You can also test keys and examples at URL for another implementation. I am pretty confident in the values in the examples, but if there are in fact bugs in these implementations (which is always possible!) I'd love to know and fix them.
NAME you were right. I had been verifying the keys by string comparison, so I fixed that. I also worked out what the Java names for the various algorithms were and got nearly all the tests to run on JS and Java platforms. But there is one error left that is consistent across both, so I wrote it up here. URL
Nevertheless, I have not yet been able to import the private key PEM file in JS. So I looked for a way to convert it to JWK to see how that would fare. I looked online, but none of the services worked, I looked at npm but that did not work, finally I found in Java that did the conversion in 2 lines of code. With this I could get signing to work: So there is something problematic with that PEM, at least insofar as it makes it very difficult to get the example to work in JS which should be one of the main platforms. (I have not yet verified the signature in JS as I am having trouble getting verification in JS to work with a valid PSS key, even though I can create the public key with the PEM, and am able to do that Scala-JS)
I think I found the problem to be with the private key. After going through this process: transforming the spec key to JWK as described above transforming the JWK to PEM PKCS1 using node's I get the following transforming the above using Java's Bouncy Castle to PEM I get this: And with that all the JS crypto API tests pass. See the .
Code change:
compliant implementation. Remove any obsolete line-folding within the line and replace it <del> with a single space (""), as discussed in MESSAGING.  Note that </del> <ins> with a single space (" "), as discussed in MESSAGING.  Note that </ins> this behavior is specific to MESSAGING and does not apply to other versions of the HTTP specification. Concatenate the list of values together with a single comma (",") <del> and a single space ("") between each item. </del> <ins> and a single space (" ") between each item. </ins> The resulting string is the canonicalized component value.

Related discussion:
text: I think to understand why that final private key works with the Java Web Crypto API but not the original one from which it was derived (which worked with Bouncy-Castle) we'd need the input of someone like NAME . With that public key replaced (in commit ) and a few others commits to get Continuous Integration to work, we have all the tests pass for Scala compiled to JavaScript Those running in the browser are a bit interleaved due to asynchronous execution, something that needs still to be fixed.
Looks good!
Code change:
the priority update. The priority update value in ASCII text, encoded using Structured <del> Fields. </del> <ins> Fields.  This is the same representation as the Priority header field value. </ins> When the PRIORITY_UPDATE frame applies to a request stream, clients SHOULD provide a Prioritized Stream ID that refers to a stream in the

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> same "Object Send Order". </del> <ins> "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.