jiebi/CodeConvo huggingface dataset:
Code change:
all the same requirements as for UDP proxying (RFC9298), and are subject to the same validation rules.  The client MUST substitute the destination host and port number into this template to produce the <del> request URI. </del> <ins> request URI.  The derived URI serves as the destination of a Capsule Protocol connection using the Upgrade Token "connect-tcp" (see registration in new-upgrade-token). When using "connect-tcp", TCP payload data is sent in the payload of a new Capsule Type named DATA (see registration in data-capsule). The ordered concatenation of DATA capsule payloads represents the TCP payload data. An intermediary MAY merge and split successive DATA capsules, subject to the following requirements: There are no intervening capsules of other types. The order of payload content is preserved. </ins> 3.1.

Related discussion:
text: This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
HTTPS over a mutually-authenticated TLS connection.  Use of the header fields outside that intended use case, however, may undermine the protections afforded by TLS client certificate authentication. <del> Therefore, steps MUST be taken to prevent unintended use, both in sending the header field and in relying on its value. </del> <ins> Therefore, steps such as those described below need to be taken to prevent unintended use, both in sending the header field and in relying on its value. </ins> Producing and consuming the "Client-Cert" and "Client-Cert-Chain" header fields SHOULD be configurable options, respectively, in a TTRP

Related discussion:
text: AD review feedback (thread at URL) and some minor editorial updates
thanks Mike, nits have been addressed
Looks good; two nits.
Code change:
ORIGIN frame is sent from servers to clients on the server's control stream. <ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification does not define a mechanism for communicating such flags in HTTP/3. </ins> 2.1. The ORIGIN frame has a nearly identical layout to that used in

Related discussion:
text: in the manner discussed in London: Admitting it exists, but we don't care.
Section 2 of includes these nuggets: to this specification MAY define flags. See . and but future updates to this specification (through IETF consensus) might use them to change its semantics. The first four flags (0x1, 0x2, 0x4, and 0x8) are reserved for backwards-incompatible changes; therefore, when any of them are set, the ORIGIN frame containing them MUST be ignored by clients conforming to this specification, unless the flag's semantics are understood. The remaining flags are reserved for backwards-compatible changes and do not affect processing by clients conformant to this specification. HTTP/3 frames don't have a Flags field in the generic frame layout. So, while I'm not sure we'll ever see a use of these flags in H2 ORIGIN, it might bite us later if it happened. I see a few options for dealing with this: Option 1) Defer. Future us will have a job to do trying to make H2 and H3 compatible if a flags related change is proposed. Perhaps its worth a little note to make sure people are aware of this divergence consideration. Option 2) Add a Flags field () to the HTTP/3 frame and add in all the same considerations about backards-(in)compatibility Option 3) Encode the flags in the frame type by picking a large enough value. A bit yuck. I'm leaning towards option 1.
Code change:
3.2. <del> The output of the exporter is a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key.  The resulting signature is then transmitted to the server using the Authorization field. </del> <ins> The key exporter output is 48 bytes long.  Of those, the first 32 bytes are input to the signature and the next 16 bytes are sent alongside the signature.  This allows the recipient to confirm that the exporter produces the right values.  This is described in fig- output: The key exporter context contains the following fields: </ins> 4.

Related discussion:
text: In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this
Code change:
specific (typically based on prior business agreement). Relays respond with "ANNOUNCE OK" and/or "ANNOUNCE ERROR" control <del> messages providing the results of announcement. </del> <ins> messages providing the results of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of either an OK or ERROR. </ins> OBJECT message header carry short hop-by-hop Track Id that maps to the Full Track Name (see message-subscribe-ok).  Relays use the Track

Related discussion:
text: one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.
Code change:
The "access_token" value MUST be the Txn-Token JWT The "issued_token_type" value MUST bet set to <del> "urn:ietf:params:oauth:token-type:txn-token" </del> <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> The response MUST NOT include the values "expires_in", "refresh_token" and "scope"

Related discussion:
text: We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.
Code change:
messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC7230 where the server decides whether to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. </ins> 2. This document designates the following headers, defined further in

Related discussion:
text: painful words in an attempt to explain renegotiation's applicability with client-cert header to
NAME wrote: possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth. And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782. <del> 7.7.1. </del> <ins> 7.9. </ins> An IETF transport is not tied to a specific Internet path or type of path.  The set of routers that form a path can and do change with

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:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> search", "match-dest", "ttl", and "type". </del> <ins> search", "match-dest", "ttl", "id", and "type". </ins> 2.1.1.

Related discussion:
text: This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!
Code change:
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_DEPRECATE_RFC7540_PRIORITIES setting is defined by this </del> <ins> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are expected to use an alternative, such as the scheme defined in this specification. <del> The value of SETTINGS_DEPRECATE_RFC7540_PRIORITIES MUST be 0 or 1. Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del> <ins> The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter value after the first </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first </ins> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR.

Related discussion:
text: RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.
Code change:
Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. <del> For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </del> <ins> For example, if a cross-site top-level request is made to a sensitive page that request will be considered cross-site and "SameSite=Strict" cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive "SameSite=Strict" cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are

Related discussion:
text: A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.
Code change:
combine the priority information from client requests and server responses to correct or amend the precedence.  Clients cannot interpret the appearance or omission of a Priority response header as <del> acknowledgement that any prioritization has occurred. </del> <ins> acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server- scheduling and client-scheduling. </ins> Priority is a Dictionary (Section 3.2 of STRUCTURED-FIELDS):

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:
through the replay of requests that are expensive to handle.  A server that is under load SHOULD prefer rejecting TLS early data as a whole rather than accepting early data and selectively processing <del> requests.  Generating a 503 (Service Unavailable) or 4NN (Too Early) </del> <ins> requests.  Generating a 503 (Service Unavailable) or 425 (Too Early) </ins> status code often leads to clients retrying requests, which could result in increased load.

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
MUST define an algorithm for selecting a result.  It MUST return a list of available-values that are suitable for the request, in order of preference, given the value of the request header <del> nominated above and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </del> <ins> nominated above (or null if the request header is absent) and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </ins> backports fulfils these requirements for some existing proactive content negotiation mechanisms in HTTP.

Related discussion:
text: This change passes 'null' to the content-negotiation algorithm if the request header is absent. For list headers, the algorithms can always turn that into the empty list, but for non-list headers they need to come up with something appropriate to do. This also tries to do better about , but may not completely fix it.
Thanks.
URL says "... For each variant in variants-header ... Let request-value be the field-value(s) associated with field-name in incoming-request." I don't see any handling of the case where there is no header in . The algorithms in URL then also don't handle the case where request-value is empty. Sorry if I've just missed where you handle the empty case.
Code change:
A client that generates an OPTIONS request containing a payload body MUST send a valid <del> header field describing the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource. </del> <ins> header field describing the representation media type.  Note that this specification does not define any use for such a payload. </ins> Responses to the OPTIONS method are not cacheable.

Related discussion:
text: () work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.
Code change:
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the <del> absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </del> <ins> absence of mandatory pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </ins> A request or response that includes message content can include a

Related discussion:
text: Only pseudo-header fields can be mandatory, so no point saying anything about fields more generally here.
sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see Section 8.2). Are there any mandatory fields that are not pseudo-header fields?
Code change:
" (content.negotiation). <del> This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. </del> <ins> This document defines HTTP range requests, partial responses, and the multipart/byteranges media type. </ins> This document obsoletes the portions of RFC7230 that are independent of the HTTP/1.1 messaging syntax and connection management, with the

Related discussion:
text: draft-ietf-httpbis-semantics says in the intro: the multipart/byteranges media type. Is this truly something specific to 1.1? Are there difference in other versions?
Good catch.
okay (editorial)