jiebi/CodeConvo huggingface dataset:
Code change:
Let param_value be the result of running Parsing a Bare Item (parse-bare-item) with input_string. <del> Append key param_name with value param_value to parameters. </del> <ins> Append key param_name with value param_value to parameters.  If parameters already contains a name param_name (comparing character-for-character), overwrite its value. </ins> Return parameters.

Related discussion:
text: NAME Thank you for the explanation. But I wonder if it is actually the case that what those specifications forbid is having duplicate header fields, rather than forbidding duplicate dictionary members (or maybe both). By quickly searching on URL, I was able to find the prohibition on having duplicate header fields, but could not find a rule that forbids having duplicate policy tokens. Assuming that at least such specifications forbid having duplicate header fields, and based on the fact that SH draft does not forbid that (when a list or dictionary is used), I think there is no reason for the SH draft to forbid having duplicate dictionary members.
NAME NAME any comments re: the above? Specifically, if SH swallowed duplicate dictionary values rather than raising an error, would that be a concern from a security standpoint?
Given a header like , it seems like we have a few options: Fail parsing. Return . Return . Return . I think I can come up with arguments for any of these options, though I'd find 4 a bit surprising as a spec author, insofar as I'd have to deal with unexpected lists for all my dictionary values. of URL skips duplicate CSP directives. That is, it picks 2 out of the list above, choosing to retain only the first value for a given name. I do wonder whether that was the right decision, but it is consistent across browsers and provides developers with predictable behavior. We throw a warning into the console in Chrome for this case, and that's probably Good Enough.
This sounds like a bad API for working with structured header values. I'd hope that eventually we offer better APIs for operating on (what Fetch calls) header lists. I think historically there were some arguments for always using first or last based on likelihood of where header injection would happen. But I'm not sure how sound any of that rationale was. I don't think a client can reasonably protect against it. Therefore, what's most important is that the result is unambiguous and that it doesn't matter how you "spell" multiple values (commas or multiple fields or a combination) in the traditional header syntax.
Anyone have preferences between Mike's options 2 and 3?
NAME I think option 3 is preferable, because that would allow server administrators to override parameters by appending header fields.
Code change:
Let param_value be the result of running Parsing a Bare Item (parse-bare-item) with input_string. <del> Append key param_name with value param_value to parameters. </del> <ins> Append key param_name with value param_value to parameters.  If parameters already contains a name param_name (comparing character-for-character), overwrite its value. </ins> Return parameters.

Related discussion:
text: I agree that NAME that it's a hack, though sadly, I do not think we can get rid of such practice through API design on the server side. People are so used to dealing with each line of header fields than working through a API that deals with a set of header fields as a whole.
There are CDNs that offer JS or Wasm APIs effectively using et al. Once structured header values are more baked and have dedicated on-the-wire support I'd definitely like to add first-class support to objects.
I weakly prefer "first one wins" (2). It's only an aesthetic preference, however: I don't have any principled reason to pick 2 over 3 or vice-versa. I can live with either for the reasons NAME spells out.
If I had pick, I probably agree with NAME reasoning.
PTAL
Thank you for the changes. Looks good to me now. FWIW, I was bit surprised to learn that we do not mention how a duplicate is processed alongside the type definitions in . I checked and now I understand that the formal definition is provided in section 4.
Code change:
even if the criteria indicate an unsatisfactory result for these scenarios. <del> In general, measurements from Internet-scale deployments will not expose the properties of operation in these scenarios, as they are statistically small. </del> <ins> In general, measurements from Internet-scale deployments might not expose the properties of operation in each of these scenarios, because they are not as ubiquitous as the General Use scenarios. </ins> 5.1.

Related discussion:
text: The second paragraph of 5 reads: I probably agree that some of the scenarios are statistically small, and may remain that way in the future, but others aren't all that statistically small even today and/or could become less small in the foreseeable future. AQM is now reasonably widely deployed, anyone with Starlink internet sees varying delay, most Wi-Fi links exhibit periodic transient link disconnections during channel scanning, etc. I'd suggest something like: The first paragraph of 5.7 Transient Events reads: The [Tools] link takes one to URL, where Section 17 provides us with: Was this intended to be a joke? .... Actually, I think you meant Section 16.
This is indeed long-since expired: title: Tools for the Evaluation of Simulation and Testbed Scenarios target: "URL" seriesinfo: Work in Progress date: 2007-7 author: - ins: S. Floyd - ins: E. Kohler.
WFM
Code change:
instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. <ins> When using HTTP2, clients SHOULD instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. </ins> 3.1. When an alternative service is advertised using Alt-Svc, it is

Related discussion:
text: Two minor things here: more strongly recommend the use of the frame type in HTTP/2 over the header field add a frame type number (no need to defer the choice now, this lets people build code based on this)
Code change:
Media over QUIC Transport <del> draft-ietf-moq-transport-00 </del> <ins> draft-ietf-moq-transport-latest </ins> Abstract

Related discussion:
text: Can we PLEASE number editor's drafts as draft-ietf-moq-transport-latest? Currently, it says draft-00, which can result is significant confustion with respect to the last published draft and creates an unstable interop target.
+1 this shouldn't have been checked in.
Code change:
5.2.2. <ins> The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL 5.2.3. </ins> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would

Related discussion:
text: Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.
Code change:
11.1. <del> Response splitting (a.k.a, CRLF injection) is a common technique, </del> <ins> Response splitting (a.k.a., CRLF injection) is a common technique, </ins> used in various attacks on Web usage, that exploits the line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections Klein.  This

Related discussion:
text: It is spelled as Acknowledgments in every RFC. Fix the one inconsistent case instead.
FWIW, I checked the style guide. Will check again. That doesn't support what you say. The current text uses the slightly minority spelling which is also the one used in the RFC Styled Guide. Feel free to flip to the other spelling if you have a strong preference.
Well, FFS, the style guide also says to use either US spelling or British spelling, but not both. It is spelled Acknowledgments in the US and all RFCs prior to that style guide. The RFC editor deliberately changed my text to Acknowledgments the last time this came up. I don't care which way it is spelled.
[x] Section 9.1. , paragraph 2, comment: I'm not sure I understand what is meant by "transport link" and how connections would "apply" to one. Editors: URL
[x] Section 9.4. , paragraph 4, comment: Using larger number of multiple connections can even cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. Editors: URL
[x] Section 13.1. , paragraph 14, comment: This can become an informative reference, so to not create a DOWNREF, since it's only used in the description of an IANA codepoint. Editors: URL
[X] Section 13.2. , paragraph 12, comment: I think it is common practice to normatively cite an RFC that is being obsoleted. Editors: URL
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Code change:
11.1. <del> Response splitting (a.k.a, CRLF injection) is a common technique, </del> <ins> Response splitting (a.k.a., CRLF injection) is a common technique, </ins> used in various attacks on Web usage, that exploits the line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections Klein.  This

Related discussion:
text: [X] Section 9.3. , paragraph 3, nit: This got garbled, the suggestion was to rephrase to: A recipient determines whether a connection is persistent or not based on the protocol version and Connection header field in the most recently received message (Section 7.6.1 of [Semantics]), if any: Editors: URL
[X] Section 11.2. , paragraph 2, nit:[X] Section 12.3. , paragraph 3, nit: Editors: this is intentional. Leave it to the RFC Editor?
[X] Section 7.1.1. , paragraph 6, nit: Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Editors: URL
[x] Section 9.5. , paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] Section 9.8. , paragraph 2, nit: The abbreviation is missing a period after the last letter. Editors: URL
[X] Section 10.2. , paragraph 17, nit: Consider using "many". Editors: this is in 11.4. URL
[x] "Appendix B. ", paragraph 2, nit: Did you mean "ought to stop"? Editors: URL
[x] "B.3. ", paragraph 2, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. [x] "B.4. ", paragraph 1, nit: Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Editors: URL
[x] "C.2.2. ", paragraph 4, nit: This abbreviation for "identification" is spelled all-uppercase. Editors: URL
[x] Uncited references: [RFC7231]. Editors: URL
[x] Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose).
Code change:
11.1. <del> Response splitting (a.k.a, CRLF injection) is a common technique, </del> <ins> Response splitting (a.k.a., CRLF injection) is a common technique, </ins> used in various attacks on Web usage, that exploits the line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections Klein.  This

Related discussion:
text: Editors: this is indeed intended, as we're citing something that is in 2068 but not 2616
[x] These URLs point to URL, which is being deprecated: URL URL Editors: these are added by xml2rfc; you may want to open a ticket for that tool :-)
[x] These URLs in the document can probably be converted to HTTPS: URL Editors: URL
It is used normatively for the definition of the "compress" coding. (also, this is no change from RFC 723x).
Sorry? We are obsoleting that spec, thus we will not have a normative dependency on it.
would "apply" to one. Suggest:
otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. With some light editing, I think this would be useful to add.
I think we should commit this now and let the RFC editor decide on spelling.
Code change:
4.5. <ins> Warp's specification attemps to map Group of Picture encoding of video on top of QUIC streams.  It depends on ISOBMFF containers to encapsulate both media as well as messaging, and defines prioritisation with separate considerations for audio and video.  It doesn't yet define bi-directionality of media flows, and can be run over protocols like WebTransport I-D.draft-ietf-webtrans-overview. 4.6. </ins> Both QRT and the Engelbart draft attempt to use existing payloads of RTP, RTCP, and SDP, unlike RUSH and SRT, as well as using existing Datagram frames All drafts take differing approaches to flow/stream identification and management; some address congestion control and others just omit the subject and leave it to QUIC to handle <del> Both QRT and RUSH specify ALPN identification; the Engelbart and SRT drafts do not. Note - need to add WARP and verify these characterizations. </del> <ins> Both QRT and RUSH specify ALPN identification; the Engelbart, Warp, and SRT drafts do not. </ins> <del> 4.6. </del> <ins> 4.7. </ins> It's worth noting that work on "RTP over QUIC" is being considered in the AVTCORE working group at this time, although no proposals have

Related discussion:
text: (related to )
NAME could you please take a look and let me know if it's an accurate description?
I'm merging this, so we make sure that WARP is included. If we got anything wrong, please let us know - we'll make sure it gets fixed.
Luke Curley has written . It's QUIC based, using CMAF for encapsulation, stream based, has no ALPN amongst other features. That said, it should be included in the "prior art" section of the document.
Agreed!
Some things worth considering, but you guys decide what is worth mentioning. Warp is the only protocol that is not frame based. Instead it attempts to map the GoP structure to QUIC streams. High quality media is basically linear within a GoP in order to maximize compression, which fits very nicely with QUIC's streams. There's no point delivering frames out of order if they cannot be decoded out of order. Warp uses prioritization instead of deadlines to achieve dynamic latency. This removes the need for feedback outside of QUIC ACKs. It avoids a whole class of problems caused by dropped/delayed feedback. Warp uses CMAF segments for full compatibility with HLS/DASH, avoiding transmuxing on edge or at origin. Warp uses the full suite of QUIC functionality. This includes fragmentation, congestion control, flow control, streams (multiplexing + cancellation), etc. Some other protocols use QUIC datagrams and disable everything else, effectively using QUIC as a complex DTLS replacement. Warp supports a bidirectional API using QUIC streams however this was not in scope for the first version of the draft. I wanted to avoid bike shedding to focus instead on the above features. The actual version in production allows the player to manually choose the rendition and pause/play. Warp uses WebTransport at the moment, but we can decide if it's better suited for native QUIC (with ALPN) or even HTTP/3. Warp would even work over HTTP/2 (and Http2Transport) albeit with additional head-of-line blocking.
Code change:
If type is "integer": <del> Parse input_number as an integer and let output_number be the product of the result and sign. </del> <ins> Let output_number be an Integer that is the result of parsing input_number as an integer. </ins> Otherwise:

Related discussion:
text: OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.
Code change:
Txn-Tokens are expected to be short-lived (order of minutes, e.g., 5 minutes), and as a result MAY be used only for the expected duration <del> of an external invocation.  If a long-running process such as an batch or offline task is involved, it can use a separate mechanism to perform the external invocation, but the resulting Txn-Token is still short-lived. </del> <ins> of an external invocation.  If the token or other credential presented to the Txn-Token service when requesting a Txn-Token has an expiration time, then the Txn-Token MUST NOT exceed the lifetime of the originally presented token or credential.  If a long-running process such as an batch or offline task is involved, it can use a separate mechanism to perform the external invocation, but the resulting Txn-Token is still short-lived. </ins> 2.4.

Related discussion:
text: Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations
Code change:
specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. <del> 2.3.2. </del> <ins> 2.4.2. </ins> Each track MAY have one or more associated connection URLs specifying network hosts through which a track may be accessed.  The syntax of

Related discussion:
text: I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments
Code change:
registries to indicate that HTTP header field registrations have moved, with an appropriate link. <del> After that is complete, please update the registry with the header field names listed in the table of field.names. </del> <ins> After that is complete, please update the new registry with the header field names listed in the table of field.names. Finally, please update the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to RFC2616 (for the definition of the header field) and RFC7231 (which removed the field definition from the updated specification). </ins> 13.5.

Related discussion:
text: I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.
Code change:
Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from <del> asynchronous close events. When an inbound connection is closed prematurely, a client MAY open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent methods (idempotent.methods). </del> <ins> asynchronous close events.  The conditions under which a client can automatically retry a sequence of outstanding requests are defined in idempotent.methods. </ins> 9.4.2.

Related discussion:
text: As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.