jiebi/CodeConvo huggingface dataset:
Code change:
While some of the frame and stream layer concepts are isolated from HTTP, this specification does not define a completely generic frame layer.  The frame and stream layers are tailored to the needs of the <del> HTTP protocol and server push. </del> <ins> HTTP protocol. </ins> 2.2.

Related discussion:
text: I'm working on the wrong machine and my setup needs tuning. I'll just drop the errant commit.
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag.
Code change:
While some of the frame and stream layer concepts are isolated from HTTP, this specification does not define a completely generic frame layer.  The frame and stream layers are tailored to the needs of the <del> HTTP protocol and server push. </del> <ins> HTTP protocol. </ins> 2.2.

Related discussion:
text: This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12. ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13.
Code change:
While some of the frame and stream layer concepts are isolated from HTTP, this specification does not define a completely generic frame layer.  The frame and stream layers are tailored to the needs of the <del> HTTP protocol and server push. </del> <ins> HTTP protocol. </ins> 2.2.

Related discussion:
text: ----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. FP: Do these two sentences contradict each other?
Code change:
While some of the frame and stream layer concepts are isolated from HTTP, this specification does not define a completely generic frame layer.  The frame and stream layers are tailored to the needs of the <del> HTTP protocol and server push. </del> <ins> HTTP protocol. </ins> 2.2.

Related discussion:
text: In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Assuming the BCP stuff gets merged via the other PR first.
Code change:
4. <del> 4.1. </del> To limit the memory requirements on the decoder side, the dynamic table is constrained in size. <ins> 4.1. The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </ins> Protocols that use HPACK determine the maximum size of table that the encoder is permitted to use.  In HTTP/2, this value is determined by the SETTINGS_HEADER_TABLE_SIZE setting (see HTTP2).

Related discussion:
text: For . Here, I moved the text that covers the calculation of the dynamic header table size up into a new section. Then, I reworded the text to reduce the direct dependency on HTTP/2 and its settings. The emphasis is now on the using protocol setting a maximum, of which the HTTP/2 setting is just an example. Apologies for the diff, I'll try to split the move commit out to make it more readable.
OK, the first commit does the rewording, the second only moves text around.
Code change:
5. This document registers a new setting in the "HTTP/3 Settings" <del> registry (HTTP3). </del> <ins> registry (HTTP/3). </ins>

Related discussion:
text: NAME - that does not seem to work as expected. See the output at URL
Understood. I personally inline everything always, so outages, bugs, and not-yet-published states simply do not affect me :-)
Please note that, per the rest of this cluster of documents, the reference citation strings "[HTTP2]" and "[HTTP3]" have been changed to "[HTTP/2]" and "[HTTP/3]", respectively. Please let us know any objections.
That does not seem to work as expected, see output at URL
See URL for how to do this in Markdown
I struggled with this in my own draft, the instructions in the style guide didn't seem to work, guessing they will once the RFCs are actually published. I copied Mikes approach, but H3 dgram solved it with what looks like a simpler approach URL
They key part is that "/" can not be in the reference name (because it's not legal in an XML ID), thus needs to go into "title". That may not have worked locally unless you have a recent version of kramdown-rfc2629.
If I do and ref RFC91113. Then make causes kramdown to blurt out and the HTML output is Versions:
Oh, that's because the XML reference file will not exist until that RFC is published. You need to inline all the information.
yeah, that's what I meant by my unclear statement "Mike's approach" - see URL But that's like a million miles off what the style guide suggests, and is annoying while we are stuck in this temporary purgatory :D
So there are two issues here combined: citing something as RFC which is not published overwriting the reference name The latter thing is what the style guide describes; for the first issue only inlining everything helps. (I personally inline everything anyway, so it didn't occur to me that that's the problem you encountered :-)
AH! Thanks for the info and pointers. I've sent out to fix.
I didn't even know what David did was possible. Magic!
Code change:
10.1. This section requests registration of the following media types <del> [@RFC2046] in the "Media Types" registry [@IANA.MediaTypes] in the manner described in [@RFC6838]. </del> <ins> RFC2046 in the "Media Types" registry IANA.media-types in the manner described in RFC6838. </ins> To indicate that the content is an scitt configuration represented as JSON:

Related discussion:
text: This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures
Code change:
value in the protected resource metadata document received by the client. <del> 7.3. </del> <ins> 7.4. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to

Related discussion:
text: "The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."
Code change:
Digest-algorithm values are used to indicate a specific digest computation. <del> All digest-algorithm values are case-insensitive but lower case is preferred. </del> <ins> All digest-algorithm token values are case-insensitive but lower case is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. </ins> <del> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed below. </del> <ins> The Internet Assigned Numbers Authority (IANA) maintains a registry for digest-algorithm values.  The registry is initialized with the tokens listed below. </ins> <del> Some digest-algorithms, although registered, rely on vulnerable algorithms and MUST not be used: </del> <ins> Deprecated digest algorithms MUST NOT be used: </ins> "md5", see CMU-836068 and NO-MD5;

Related discussion:
text: [x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too
Code change:
The "type" value is optional and defaults to "raw". <del> 2.1.4. </del> <ins> 2.1.6. </ins> The "hashes" value of the Use-As-Dictionary header is a inner-list value that provides a list of supported hash algorithms in order of

Related discussion:
text: This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,
Code change:
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <del> 7.1.1. </del> <ins> 7.2. </ins> Some equipment in the network uses an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set

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:
Insecure digest algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial <del> setting; for example, when signing the digest of content for </del> <ins> setting; for example, when signing digest fields' values for </ins> authenticity. The registry is initialized with the tokens listed below.

Related discussion:
text: Consistent use of "checksum".
From NAME WGLC review: Personally, I think the use of both terms is ok. Mainly because digest is overloaded in the document. But it wouldn't hurt us to review the document for usages and perhaps add a note in notational conventions about the use of terms.
is a generic checksum computation, should be the actual digest algoritm computation. We need to clarify this and probably introduce new terminology.
Code change:
expiring as a dictionary in 7 days independent of the cache lifetime of the resource. <del> 2.1.6.2. </del> <ins> 2.1.7.2. </ins> A response that contained a response header:

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:
used a Subscribe ID equal or larger than the current Maximum Subscribe ID. <del> GOAWAY Timeout: The session was closed because the client took too </del> <ins> GOAWAY Timeout: The session was closed because the peer took too </ins> long to close the session in response to a GOAWAY (message-goaway) message.  See session migration (session-migration). 3.6. <del> MoqTransport requires a long-lived and stateful session.  However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media.  MoqTransport avoids this via the GOAWAY message (message-goaway). </del> <ins> MOQT requires a long-lived and stateful session.  However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media.  MOQT enables proactively draining sessions via the GOAWAY message (message-goaway). </ins> <del> The server sends a GOAWAY message, signaling that the client should establish a new session and migrate any active subscriptions.  The GOAWAY message may contain a new URI for the new session, otherwise </del> <ins> The server sends a GOAWAY message, signaling the client to establish a new session and migrate any active subscriptions.  The GOAWAY message optionally contains a new URI for the new session, otherwise </ins> the current URI is reused.  The server SHOULD terminate the session with 'GOAWAY Timeout' after a sufficient timeout if there are still <del> open subscriptions on a connection. </del> <ins> open subscriptions or fetches on a connection. </ins> <del> The GOAWAY message does not immediately impact subscription state.  A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new SUBSCRIBEs while in the draining state.  When the server is a subscriber, it SHOULD send a GOAWAY message to downstream subscribers prior to any UNSUBSCRIBE messages to upstream publishers. </del> <ins> When the server is a subscriber, it SHOULD send a GOAWAY message to downstream subscribers prior to any UNSUBSCRIBE messages to upstream publishers. </ins> After the client receives a GOAWAY, it's RECOMMENDED that the client waits until there are no more active subscriptions before closing the

Related discussion:
text: My current thinking is that GOAWAY is useful for all publishers, even if they're 'clients' (ie: an original publisher). It also seems useful if an original publisher is publishing to an ingestion server that is about to restart and the server wants to cause them to connect to a different ingestion server. I don't have a clear use for the end subscriber sending a GOAWAY, but it also doesn't seem particularly harmful.
I think you missed a few spots to update (suggestions made), but maybe you intentionally left those as is?