jiebi/CodeConvo huggingface dataset:
Code change:
compatible assigned to the nominated registrations, prefixing each with "*" to indicate that it is a retrofit type. <del> Then, add the field names in new-fields, with the corresponding Structured Type as indicated, a status of "permanent" and referring to this document. </del> Finally, add a new column to the "Cookie Attribute Registry" established by COOKIES with the title "Structured Type", using information from cookie-params.

Related discussion:
text: Or it might reject all mapped field names from A, on grounds that it must have been invalid. Moreover, "intermedaries" has to be intepreted very loosely. Every processing step in the entire HTTP pipeline needs to carefully manage these alternate names. This seems a disaster waiting to happen. I think I'm now convinced this is the only plausible option. Regarding "many contexts" and "some", do you have use cases in mind here? I saw draft-nottingham-binary-structured-headers, but I gather there are others? Something to keep in mind is that this draft intentionally punts figuring out the negotiation design to the future anyway. That means this is also the more flexible option. If we define , etc., now, we have permanently committed ourselves to this security problem. If we decline to define now, we can still choose. We can always define the parallel field names later, should something that needs them come up. (Of course, I'd raise the security problem again, but it'll be easier to reason about with a concrete use case! )
I guess this raises another question: how do we handle mapped field values that cannot be represented in the underlying text representation? Given how many intermediaries and intermediary-like constructs are involved in HTTP pipelines, and given how every HTTP system today uses the current syntax, I suspect mapped values that cannot be represented in the original syntax have to be treated as an error. Which means I think we need to go through the exercise of writing SF-to-text converters for each mapped field and then narrowing the allowed inputs until that converter is infallible.
It sounds like removing the field names is the best path forward. Yes, for those, the application using retrofit needs a fallback, just as it does for compatible fields. If that isn't obvious from the document, it should be clarified -- perhaps in a new 'Using Retrofit Fields' section.
I could very well be incorrect, but it sounds we want to have alternatives per each hop. Does that mean that these mappings would be best represented by ther per-hop pseudo headers that we have in H2 and H3? Not that I feel that doing so would be the best option, though.
Ooh yeah, per-hop is a good way to think about this! For pseudoheader vs. something else, I suspect it'll depend on use?
Code change:
compatible assigned to the nominated registrations, prefixing each with "*" to indicate that it is a retrofit type. <del> Then, add the field names in new-fields, with the corresponding Structured Type as indicated, a status of "permanent" and referring to this document. </del> Finally, add a new column to the "Cookie Attribute Registry" established by COOKIES with the title "Structured Type", using information from cookie-params.

Related discussion:
text: draft-nottingham-binary-structured-headers already has a flag, so it probably could just use the original names, though pseudoheader names would work too I suppose. The existing names has the minor benefit of being able to reuse the existing HPACK static table. Some sort of SF-based HTTP API like probably (?) doesn't want pseudoheaders in the API and can just use the original names. But I haven't put much thought into that. If one wanted to send them in their textual form in existing frames, we probably need pseudoheaders. Though I don't know if we really get much value out of defining that, over just using the existing syntax. shrug We can also punt this problem to documents that want to use this, if we're not sure yet. :-)
If you want to use an invalid field name, there are a lot more options than putting a ":" in the first byte. You need to negotiate that usage, but then you can do anything at all, including using that to signal lots of stuff. (If you want to avoid the extra byte, you can pack data into the high bit of each byte...)
I feel like punting is the right solution, unless we can come up with a convention that addresses the identified issues in all cases.
Not acting is a decision of a sort. But I'm not sure what that would concretely mean for retrofit? No prefix? Or just that we shouldn't worry yet about the effect this has on smuggling through WAFs and whatnot?
I think it means: No new header names; applications that use mapped fields need to define their own way to distinguish them A new section about these considerations
Code change:
17.4. <ins> This specification updates the HTTP related aspects of the existing registration procedures for message header fields defined in RFC3864. It defines both a new registration procedure and moves HTTP field definitions into a separate registry. </ins> Please create a new registry as outlined in field-name.registry. After creating the registry, all entries in the Permanent and

Related discussion:
text: IIUC httpbis-semantics changes the field name registry, thus updating BCP 90 / RFC3684. Is that correct? Should httpbis-semantics mention that? NAME
"obsoletes": no, because BCP 90 is also for email. "updates": yes, I think so. NAME
Hm; I suppose so, given that it's taking some of 3684's turf away.
Now does that make SEMANTICS part of BCP90?
I'm inclined to say no -- it modifies the scope of BCP90 to exclude HTTP header fields. Worth discussing more broadly, though.
Code change:
2.1. <del> An HTTP header field value is identified by its header field name. While HTTP header field names are case-insensitive, implementations SHOULD use lowercased field names (e.g., "content-type", "date", "etag") when using them as content identifiers. </del> <ins> An HTTP header field is identified by its header field name.  While HTTP header field names are case-insensitive, implementations MUST use lowercased field names (e.g., "content-type", "date", "etag") when using them as content identifiers. </ins> An HTTP header field value is canonicalized as follows:

Related discussion:
text: Strengthened requirement for content identifiers for header fields to be lower-case (changed from SHOULD to MUST). Relaxed guidance on processing Creation Time and Expiration Time to only require verifiers to examine them and test against the verifier’s requirements. Minor editorial corrections and readability improvements.
The current text allows mixed-case header field names when they are being used as content identifiers. This is unnecessary – header field names are case-insensitive – and creates opportunity for incompatibility. Instead, content identifiers should always be lowercase.
The processing instructions for Creation Time and Expiration Time imply that verifiers are not permitted to account for clock skew during signature verification.
This can safely be fixed adding a -like claim, so that the signer remains in control of the signature validity. This is especially important if the signature is created with the signer's private key. imho this kind of document should not define a clock-skew tolerance threshold, and implementors shoud be suggested to fix their clocks. There may be corner cases (eg. IoT/disconnected devices ) that we should address properly
I'd split the clock-skew part in a separate PR. The rest LGTM.
Code change:
incomplete successful transfer, the server MUST respond with a "409 (Conflict)" status code. <ins> While the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  These informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a success (e.g. "201 (Created)"), or when the response is a failure

Related discussion:
text: Or maybe URL
I'm not fussed on the specific response code value but the 102 seems deprecated, for whatever that means, and the linked wording seems at odds with the system design we want
It's not deprecated, but wasn't carried over to WebDAV-bis due to lack of implementations. It's in the registry, so it's a real HTTP status code. That said, I now agree it doesn't fit well, as 102 is for situations where the client is actually waiting for a response (as opposed to still sending).
I guess that's accurate to the historical record, after a very cursory delve into RFC 2518 and 4918. But I wonder how clear that interpretation is to the broader HTTP world. MDN has a perspective you might want to follow up on. Yeah this is where I'm hitting a hard edge. A registered status code, where the behaviour, the important stuff, is described in an obsoleted RFC doesn't really seem great.
FWIW, I would push back hard on that line of argument. The code is registered, so it's a valid status code. And yes, a spec that wants to use might want to either include an updated definition, or make sure the definition is moved to a separate new document.
I also think that 102 is OK to use here (but maybe a new status code is still warranted, see below). The 102 isn't depreciated as a bad idea or because of another better solution, it was merely omitted from recent updates to the WebDAV specification for lack of implementations. I imagine another specification could take over ownership of the definition/registration. I think the only reason I didn't specifically write 102 in my email is, I've to indicate "upload complete, the server is now performing additional processing" and it may be useful to distinguish this signal from "upload has been partially received and committed to storage". The former is probably closer to the intended usage, so it may still be good to mint a new status code for the latter usage. Alternatively, both cases might be distinguished by the HTTP fields that are returned, and maybe servers want to indicate both at the same time ("50% committed to disk, 20% processed").
I share the view that 102 does not fit very well here.
Code change:
incomplete successful transfer, the server MUST respond with a "409 (Conflict)" status code. <ins> While the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  These informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a success (e.g. "201 (Created)"), or when the response is a failure

Related discussion:
text: It would be awkward to send an URI to which the missing part of the request should be sent, while indicating that "the server has accepted the complete request" (). If we are to choose from an existing status code, 100-continue might be a better choice, though I would prefer using a new status code considering that we did so in introducing 103. All 1xx codes are interim and therefore kind of implies continuation. We can burn a new status code for a particular case of contiuation, which Resumable Upload is.
I opened a PR for this in URL
I think this would be a good addition to the spec as long as it's not mandatory for the server to send this data. As previously stated in this thread It would help the client to discard in-memory data that is no longer required to resume. Would it make sense to also include the location header in the additional 104 responses? This would make the solution more robust in case one (or several) of the 104 responses get lost and the extra header field would not add any significant amount of extra bytes in each request.
Yes, this would be optional. I am unsure how big the benefit would actually be. This would only help if a 104 is lost without the connection being destroyed, so the HTTP response is still open and a subsequent 104 could be received. Maybe this is possible with HTTP/2 or HTTP/3, but I don't know that. Other than that, repeating Location would be redundant.
1xx response are allowed to be dropped by intermediaries. But I'm not aware of any that would drop some in a request. Typically they just swallow all or pass all.
NAME Is that so? I could be wrong but states that a proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response.
I suspect what NAME meant to say is that some proxies do drop 1xx responses, whether they're allowed to or not. Also, some HTTP libraries consume all the 1xx responses without exposing them to the caller, even if the library itself doesn't do anything with that particular 1xx code; such a library is indistinguishable from a poorly-behaved intermediary.
My concern isn't so much proxies dropping one or more response as much as e.g.
Code change:
incomplete successful transfer, the server MUST respond with a "409 (Conflict)" status code. <ins> While the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  These informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a success (e.g. "201 (Created)"), or when the response is a failure

Related discussion:
text: switching network and losing one or more of the 104 response (think spotty Wi-Fi moving over to 4G). Another input here would be consistency, especially if we add the header to the first 104. I agree that the benefit might not be huge but it's not zero either. It does however seem like the consensus in Prague was that this is not needed and I can get behind that.
One or more of the 104 responses could be dropped, along with the final response, due to the connection being interrupted, but selective 104s can't be dropped due to network issues. Clients need to deal with failed connections no matter what, so I don't see how this is an issue.
NAME Right, then this is a non-issue that can be skipped. I just wanted to bring it up so that we do not miss aspects. :)
Thanks for the feedback! I adjusted URL to clarify what header fields can be present in 104 responses.
Code change:
for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols.  Proxies are often used to group an organization's HTTP <del> requests through a common intermediary for the sake of security, annotation services, or shared caching.  Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in message.transformations. </del> <ins> requests through a common intermediary for the sake of security services, annotation services, or shared caching.  Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in message.transformations. </ins> A

Related discussion:
text: Inspired by some discussion on : while just the word "security" is indeed used in marketing literature for proxies, it's meaning to different parties is so varied so as to not really convey much useful information. In the IETF we try hard to be clear about what security provides we need and/or provide, avoiding the vague catch-all term. However (as I am reminded out of band), the audience of this document is not exactly security experts, and it is easy to go overboard trying to be precise, at least in this instance. [actual commit message body retained below] The mere act of inserting a proxy into the chain does not, in and of itself, do much of anything for the security of the system (and a badly implemented proxy can make the security of the system much worse). A proxy can, however, provide security services such as auditing access, annotating content from untrustworthy sources, exfiltration avoidance, etc. It is these services that are the security-related motivation for using a proxy, so say that "security services", rather than just "security", are being provided by the proxy.
Code change:
After sending a GOAWAY frame, the sender can ignore frames for new streams. <del> The GOAWAY frame does not define any type-specific flags. </del> <ins> The GOAWAY frame does not define any flags. </ins> The GOAWAY frame applies to the connection, not a specific stream. The stream identifier MUST be zero.

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
Abstract This document defines the core behavior for Media over QUIC Transport <del> (MOQT), a media transport protocol over QUIC.  MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </del> <ins> (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality.  MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> Media Over QUIC Transport (MOQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MOQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MOQT supports wide range of use-cases with different </del> <ins> Media Over QUIC Transport (MOQT) is a protocol that is optimized for the QUIC protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MOQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MOQT supports wide range of use-cases with different </ins> resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks.

Related discussion:
text: Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.
Code change:
The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for <del> ISO mDoc / mDL. </del> <ins> ISO mDoc / mDL.  If the Issuer is an OAuth Authorization Server according to RFC6749, it is RECOMMENDED to use "status_list_aggregation_endpoint" for its metadata defined by RFC8414. </ins> The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.

Related discussion:
text: yes, looks great.
If an OP wanted to publish the Token Status List JWT on an endpoint, perhaps something like with ... it would be nice to specify that in the spec.
I'm not sure what you are suggesting. Are you suggesting that AS or RS has a link to a status list token in his metadata or are you suggesting media types? The latter is already defined in the draft.
Is this covered by ?
Editors Call: add that may link then to the Aggreation
NAME does the PR reflect your idea?
LGTM apart from the minor text change
Code change:
The Issuer MAY link to the Status List Aggregation URI in metadata that can be provided by different means like .well-known metadata as is used commonly in OAuth and OpenID, or via a VICAL extension for <del> ISO mDoc / mDL. </del> <ins> ISO mDoc / mDL.  If the Issuer is an OAuth Authorization Server according to RFC6749, it is RECOMMENDED to use "status_list_aggregation_endpoint" for its metadata defined by RFC8414. </ins> The concrete specification on how this is implemented depends on the specific ecosystem and is out of scope of this specification.

Related discussion:
text: Rendered version: URL
We do not define how to respond to a status list request but have status codes on examples We might also need to add language for redirects?
Ok to merge with the minor suggestion.
Code change:
10.1.1.1. If a Transparency Service is honest, then a Transparent Statement <del> including a correct Receipt ensures that the Transparent Statement passed its Registration Policy and was recorded appropriately. </del> <ins> including a correct Receipt ensures that the associated Signed Statement passed its Registration Policy and was recorded appropriately. </ins> Conversely, a corrupt Transparency Service may 1. refuse or delay the Registration of Signed Statements, 2. register Signed Statements that

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later