jiebi/CodeConvo huggingface dataset:
Code change:
use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. <del> Clients MAY advertise support of other cipher suites in order to allow for connection to servers that do not support HTTP/2 to complete without the additional latency imposed by using a separate connection for fallback. </del> <ins> The effect of these restrictions is that TLS 1.2 implementations could have non-intersecting sets of available cipher suites, since these prevent the use of the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with P256 FIPS186. Clients MAY advertise support of cipher suites that are prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2.  This enables a fallback to protocols without these constraints without the additional latency imposed by using a separate connection for fallback. </ins> An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these

Related discussion:
text: Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> The following terms are defined in RFC8632 and are not redefined here:

Related discussion:
text: We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.
Code change:
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <ins> MUST NOT modify "sub" and "aud" values of the Txn-Token in the request MUST NOT remove any of the existing requesting workload identifiers from the "req_wl" field in the "rctx" claim of the Txn-Token </ins> 7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token

Related discussion:
text: a replacement request. Removed vague language
There was a point in Yaron's about specifying in 7.4.1 that sub must be unchanged, and although this is mentioned in 7.4, perhaps we should add bullet points in 7.4.1 (Txn-Token Service Responsibilities) that specify that MUST NOT be modified and MUST NOT be modified.
LGTM
Code change:
2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del> <ins> The ABNF (Augmented Backus-Naur Form) syntax for the `Tunnel- Protocol` header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) must

Related discussion:
text: This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.
Code change:
degrade spray attacks, but do not prevent more targeted attacks that are executed with lower volumes and velocity.  Therefore, it should be used along with other techniques to provide a defence-in-depth <del> against cross-device attacks. </del> <ins> defence against cross-device attacks. </ins> 5.1.12.

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!
Code change:
Framing and control data is sent first, followed by a header section containing fields for the headers table.  When a message includes <del> content, the content is sent after the header section and potentially interleaved with zero or more trailer sections containing fields for the trailers table. </del> <ins> content, the content is sent after the header section, potentially followed by a trailer section that might contain fields for the trailers table. </ins> Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
Framing and control data is sent first, followed by a header section containing fields for the headers table.  When a message includes <del> content, the content is sent after the header section and potentially interleaved with zero or more trailer sections containing fields for the trailers table. </del> <ins> content, the content is sent after the header section, potentially followed by a trailer section that might contain fields for the trailers table. </ins> Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while

Related discussion:
text: Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.
Code change:
Change Controller: IETF <del> Specification Document(s): referenced-token-cwt of this </del> <ins> Specification Document(s): referenced-token-cose of this </ins> specification 14.5.

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
The response for a PUSH_PROMISE stream begins with a HEADERS frame, which immediately puts the stream into the "half-closed (remote)" state for the server and "half-closed (local)" state for the client, <del> and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. </del> <ins> and ends with a frame with the END_STREAM flag set, which places the stream in the "closed" state. </ins> 8.5.

Related discussion:
text: Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.
Code change:
If dictionary already contains the name this_key, there is a duplicate; fail parsing. <del> Consume the first character of input_string; if it is not "=", fail parsing. </del> <ins> If the first character of input_string is "=": Consume the first character of input_string. Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. Otherwise: Let value be Boolean true. Let parameters be an empty, ordered map. </ins> <del> Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. </del> <ins> Let member be the tuple (value, parameters). </ins> Add name this_key with value member to dictionary.

Related discussion:
text: For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)
Code change:
If dictionary already contains the name this_key, there is a duplicate; fail parsing. <del> Consume the first character of input_string; if it is not "=", fail parsing. </del> <ins> If the first character of input_string is "=": Consume the first character of input_string. Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. Otherwise: Let value be Boolean true. Let parameters be an empty, ordered map. </ins> <del> Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. </del> <ins> Let member be the tuple (value, parameters). </ins> Add name this_key with value member to dictionary.

Related discussion:
text: I'm really not sure what happened there, but don't have time to investigate. I suspect GitHub didn't actually merge.
Code change:
5.3.2. <del> The proposed congestion control algorithm ought to discuss whether it </del> <ins> A congestion control algorithm proposal MUST discuss whether it </ins> allows for incremental deployment in the targeted environment.  For a <del> mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </del> <ins> mechanism targeted for deployment in the current Internet, the proposal SHOULD discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </ins> Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the

Related discussion:
text: All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.
Code change:
components of the URI reference RFC3986, if any, when generating the Referer field value. <ins> The field value is either an or a . In the latter case (uri), the referenced URI is relative to the target URI (RFC3986). </ins> The Referer header field allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc.  It also allows obsolete or mistyped links to be found for

Related discussion:
text: Text taken from existing statement in Location.
Ah, makes sense, of course. Thanks NAME
NAME - can you check again?
2616's definition of said: 7231 dropped that, thanks to . We should probably restore it, given it can cause misconceptions like .
NAME do you remember why you removed that text?
Yes, the requirement moved into the general section on all URI-references. That is not a special case. And, no, its presence or absence would have made no difference to the referenced bug report. If either one of them had correctly followed the spec, they would have been fine. Instead, npm sent a special value without a special scheme, and Cloudflare marked that for rate limiting based on incorrect assumptions of bad behavior rather than the actual specification. Excuses happen.
NAME - I wasn't talking about the actual bug; I was talking about NAME -- someone who has implemented a very good HTTP engine -- misinterpreting the spec in that comment because it was reader-unfriendly. That should concern us all, because if he and implementers like him misread the spec so easily, it will be mis-implemented. And, the fault here is definitely not with him; it's with the spec. It's not reasonable to expect people to hold the entire specification series in their heads as they interpret each phrase and requirement, especially considering that in most renderings it's not cross-referenced (and even where the renderings support it, we don't cross-reference consistently). I understand that we need to be terse sometimes, and that it's reasonable to have expectations of our readers. But, when we use arcane terms and overload widely-used terms (even if incorrectly) to the point where the only people who understand the spec on a good day are you, Julian and I (and on a bad day, just you), it doesn't do anyone any good.
I think there are two ways to resolve this: 1) Link back to the URI section in each case where it's used, and adjust language to make it clear that there are requirements there 2) Add language in each case where a URI is a protocol element, and state how it's resolved I think I prefer (2), because is vague about how it specifies this: Since Section 2 is about HTTP URIs in general -- not just as protocol elements -- it's not clear what the scope of this statement is.
Code change:
components of the URI reference RFC3986, if any, when generating the Referer field value. <ins> The field value is either an or a . In the latter case (uri), the referenced URI is relative to the target URI (RFC3986). </ins> The Referer header field allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc.  It also allows obsolete or mistyped links to be found for

Related discussion:
text: It's also not a requirement, which doesn't seem good for interoperability.
Waiting for to land.
Places this will affect: Location Content-Location Referer
I still don't see any reason for this change. The spec already states how to do relative resolution in general, which it must do because it applies to all header fields (not just the ones we define). Saying it again on every occurrence of a relative or partial URI is just adding length to the spec.
We already said it for Location, and the amount of added text is minimal.
... and it's also said explicitly in . It may be obvious to you, but it's pretty clearly not to many implementers.
The only confusion has been our change in 7231 of the Location field to allow relative references. I am not aware of anyone ever being confused about the target URI being the base URI for all header fields, but I can live with more text if it says that consistently. To reiterate, this entire issue is based on a misreading of a completely mistaken assumption about the field content of "Referer: install" being flagged as a potential security issue by Cloudflare because it is unusual, not because Cloudflare somehow might not have been aware that the syntax is allowed by the spec as a relative reference. It's defense by spec-lawyering. These changes would not have changed Cloudflare's algorithm and would not have convinced npm to choose a more common default. Actually talking to their own CDN before deploying an HTTP change would have helped. Testing would have prevented it entirely.
NAME is right that the prose needs to be in sync with the actual ABNF. Will update the PR later today with a proposal.
Code change:
On-Demand media streaming (odstream) is unlikely to benefit from work in this space.  Without notable latency requirements, protocols such <del> as HLS and DASH largely meet the needs of this use case.  However larger deployments may benefit from the use of HTTP/3 I-D.draft-ietf- quic-http. </del> <ins> as HLS and DASH largely meet the needs of this use case. </ins> 7.

Related discussion:
text: Based on feedback from NAME
That looks fabulous to me - merging now. There's not an issue for this, right?
Code change:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 7. </del> <ins> 5.4. </ins> Some technologies used for stub networks, for example Thread or 6LoWPAN mesh networks, can produce partitioned networks, where what

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.
Code change:
Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version <del> in forwarded messages.  In other words, they are not allowed to blindly forward the </del> <ins> in forwarded messages, unless it is purposefully downgraded as a workaround for an upstream issue.  In other words, an intermediary is not allowed to blindly forward the </ins> without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the

Related discussion:
text: It's written: Actually I'd rather say "MUST send a version no higher than their own in forwarded messages" (poor wording, I know, maybe someone can propose better). Indeed, if an intermediary receives an HTTP/1.0 request and passes it as HTTP/1.1, the server will wrongly assume that the client can deal with 1.1 (e.g. chunks) and the message may have to be degraded by the intermediary (such as de-chunking and rely on close only). Furthermore, seeing 1.0 for a server is often an indication of very limited (or possibly bogus) client. For example some intermediaries might avoid compressing or caching when facing HTTP/1.0 messages, and as such it's preferable to let such versions be properly advertised in messages that could be considered as potentially unsafe. Maybe a different wording should be "intermediaries... MUST NOT pass a message showing a version they do not support, and MUST make sure the message always conforms to the advertised version".
I agree with Willy: the underlying requirement is that intermediaries accept and send messages only in versions that they understand (unless acting as a tunnel, I guess). The original text basically means that, even if it is phrased in terms of what value is placed in a specific field rather than as the true requirement.
Discussed at Feb 21 interim; should work on a proposal to loosen this somewhat, at least for intermediaries. SHOULD + context?
OK let's try with that.
but see feedback from NAME