jiebi/CodeConvo huggingface dataset:
Code change:
window and the connection flow control window.  The sender MUST NOT send a flow controlled frame with a length that exceeds the space available in either of the flow control windows advertised by the <del> receiver.  Frames with zero length with the FINAL flag set (for </del> <ins> receiver.  Frames with zero length with the END_STREAM flag set (for </ins> example, an empty data frame) MAY be sent if there is no available space in either flow control window.

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (methods) and a few request-modifying <del> header fields.  If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in safe.methods, the method semantics take precedence. </del> <ins> header fields.  A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request.  For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see safe.methods). </ins> HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and

Related discussion:
text: Can you please factor the whitespace changes out into a separate PR?
Sorry, my editor did that without my knowledge. I didn't realize the draft was so messy to start with. Will do.
: This is good, but I think that the phrasing here could be more direct. "any semantic implied by the URI itself" - when you read suggests that you might infer something from a URI about what it does. However, I think that this underplays the key point. The point that should be made here is that a resource cannot decide to change the semantics of a method to suit its purposes (I guess unless it is willing to assume all responsibility for doing so, the usual caveat we apply here for things like request logging). Separately, the specific reference to 9.2.1 might be read to imply that safeness is special, but resources don't get to override the semantics of idempotent methods either (or any other well-defined properties of methods). So I would instead phrase this more directly and use the citation as an example only:
NAME can you PR that?
Sure.
Code change:
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (methods) and a few request-modifying <del> header fields.  If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in safe.methods, the method semantics take precedence. </del> <ins> header fields.  A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request.  For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see safe.methods). </ins> HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) and

Related discussion:
text: though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.
Code change:
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (methods) and a few request-modifying <del> header fields.  If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in safe.methods, the method semantics take precedence. </del> <ins> header fields.  A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request.  For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see safe.methods). </ins> HTTP relies upon the Uniform Resource Identifier (URI) standard RFC3986 to indicate the target resource (target.resource) 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:
server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del> <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client

Related discussion:
text: Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in
Code change:
server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del> <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client

Related discussion:
text: Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go.
Code change:
server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del> <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client

Related discussion:
text: Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)
Code change:
examples of Repr-Digest and Want-Repr-Digest fields in message exchanges. <del> algorithms bootstraps a new IANA registry hash algorithms and defines registration procedures for future entries. </del> <ins> algorithms presents hash algorithm considerations and defines registration procedures for future entries. </ins> 1.2.

Related discussion:
text: Murray suggested some things that we could change about the way new IANA registry was being handled. This change: tries to make it clearer that this document uses a new registry that we will need IANA to create moves rote IANA instructions to the IANA considerations better highlights interesting hash algorithm considerations for implmenters clarifies the registration procedure and expands on the expectations for the Designated Expert(s)
Code change:
commonly occurring functionality could improve and simplify interoperability between independent implementations. <del> This document aspires to standardize two HTTP header fields, "Client- Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client-Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic. While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the </del> <ins> This document describes two HTTP header fields, "Client-Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client- Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the </ins> certificate that was presented by the originating client in its connection to the TTRP.

Related discussion:
text: and use "describes" rather than "standardize" to better align w/ the Informational intended status
As Yoda might say, do or do not. We can lose the aspiration here and be assertive about the document consensus progress.
I have a tendency towards that kind of demure writing. But you and Yoda are right. Will change.
LGTM, too.LGTM
Code change:
This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names <del> "tracker.example.com" and "service1.example-cdn.com" in the DNS </del> <ins> "tracker.example.com" and "service1.example.com" in the DNS </ins> resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".

Related discussion:
text: Update example domain names to avoid "example-URL" and too-long lines
Some examples use ; IDNITS dings you for not using . Should probably use something like .
The examples in 2.1 have lines that are too long. Because it's caused by , which is a String, I think your options are: Shorten the strings Use RFC 8792 line wrapping
Code change:
behaviors, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, it uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <del> RFC5234.  It also includes the tchar rule from RFC7230. </del> <ins> RFC5234.  It also includes the tchar and OWS rules from RFC7230. </ins> When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms.  If there is

Related discussion:
text: From Magnus's feedback
also NAME PTAL
This does not instill much of a panicked reaction in me, which is probably a good sign. I trust it is intentional to not apply a similar treatment to inner lists (which also has a prose description I had commented on previously) on the grounds of them not resembling existing top-level header field structures? That's certainly defensible, though I have to wonder whether someone will simply assume that it must be the same (not that we have much hope of changing such a person's behavior).
How does this vibe with ? I know we spent a bit of time on it, but it's long enough ago that I can't recall detail.
Ah, right, I think I remember. Doing it this way means inner-list is different: The original motivation to remove tabs was because the above was going to be but there was consternation about RWS. Most of the discussion is in
NAME was where my mind went first too, but that seems to be just about in inner lists (which makes sense). I think this is separate; intermediaries that don't know about the semantics and syntactic limitations of a given field shouldn't be meddling inside it (which inner list delimitation is).
NAME I think so -- that's the only reason to allow this. Existing servers may already legitimately be using TAB when combining multiple field lines. And I suppose it makes sense, given the recent discussion about not breaking up individual list or dictionary members over multiple lines, that we don't need to replace *SP with OWS everywhere. I'm okay with this change -- does it warrant a note in the prose somewhere that this special case only exists to accommodate field concatenation? Let's hope we don't need to add VTAB or FF to this, too :)
NAME I don't know that that's necessary; we already pretty clearly. In SF, I looked at changing "whitespace", but in each case the ABNF and algorithms make it clear what we're talking about, so I don't see a strong need to disambiguate.
I'm ok with the change over here; that said, the Semantics spec could be clearer. Opened URL
NAME and I have been talking about this, and have come to the conclusion that this change went too far.
Code change:
behaviors, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, it uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <del> RFC5234.  It also includes the tchar rule from RFC7230. </del> <ins> RFC5234.  It also includes the tchar and OWS rules from RFC7230. </ins> When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms.  If there is

Related discussion:
text: Specifically, steps 1 and 5 in "Parsing Structured Fields" should just be SP, not OWS, because there isn't any risk of an intermediary inserting TAB before the first field line or after the last field line; it's only between List and Dictionary members that we need to be concerned. Reverting that part of the change also makes writing the test cases considerably simpler. See 6842793e.
This is so that field line combination as per the Semantics spec can happen, right? I note that currently says: Note that it says "comma an optional whitespace", not "OWS". Depending on how you read it, it might include other whitespace characters. I believe this needs to be fixed in the Semantics spec.I dont think I ever saw a TAB in a HTTP header in real life, but I am OK with this.
Code change:
If input_string is empty, return members. <del> Consume the first character of input_string; if it is not COMMA, fail parsing. </del> <ins> Consume the first character of input_string; if it is not ",", fail parsing. </ins> Discard any leading SP characters from input_string.

Related discussion:
text: The term COMMA is not defined anywhere in this document, or in any of the documents it imports. But we can just use the literal instead.
Thanks.
The structured headers draft imports and uses a number of productions from RFC 5234 for typographically awkward characters and character classes (, , etc), but there is no definition of provided anywhere. Similar to the way that , , , , and are used without special treatment, can probably be replaced with wherever it occurs.
Code change:
subtypes of that type.  The media-range can include media type parameters that are applicable to that range. <del> Each media-range might be followed by zero or more applicable media type parameters (e.g., </del> <ins> Each media-range might be followed by optional applicable media type parameters (e.g., ), followed by an optional "q" parameter for indicating a relative weight (quality.values). </ins> <del> ), an optional "q" parameter for indicating a relative weight (quality.values), and then zero or more extension parameters.  The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets. </del> <ins> This specification does not define "accept parameters" following the special "q" parameter, as was done in earlier editions.  Senders using weights SHOULD send "q" last (after all media-range parameters).  Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering. </ins> The example

Related discussion:
text: Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last
Code change:
a few different SD-JWT permutations, both with and without various constituent parts. <ins> As an alternative illustration of the SD-JWT format, for those who celebrate, ABNF RFC5234 for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here: </ins> 5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's

Related discussion:
text: would
It seems like it could be helpful to implementors, allowing them to quickly validate whether what they have is syntactically an SD-JWT or an SD-JWT with key binding. Something like:
The actual helpfulness of ABNF IMHO really depends on the readers familiarity with ABNF. I don't know that such familiarity is particularity prevalent. But, as long as it's correct, it doesn't hurt to include either. And while I'm not overly familiar with ABNF myself, I know enough to know that that isn't valid ABNF and doesn't quite correctly convey the SD-JWT constructs. I've endeavored to fix it up but am not 100% sure this is correct either: \ with a bit of help from https://author-URL
Looks good to me, thank you! Maybe a small improvement would be to introduce a name for disclosure?
That's a good improvement, thanks!
Looks good to me, and appears valid according to the .
(SD-JWT-KB part of the ABNF depends on another PR)
need to wait after is resolved to do a PR.
maybe add a KB-JWT line to be even more better? a la:
Not my religion, but happy to celebrate anyway.