jiebi/CodeConvo huggingface dataset:
Code change:
prefix. Response messages that contain informational status codes result in a <del> different structure; see informational. </del> <ins> different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length, it can only appear in response messages. </ins> Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.

Related discussion:
text: The diagram resulted in a few double-takes that might be helped by a little bit of a note pointing this out.
I suspect that requests do not carry the Known-Length Informational Response field (otherwise how do you know how many of them there are?) but that should be spelled out explicitly. I'd suggest creating a different diagram for known-length request vs known-length responses to make this easier to reason about, and same for indeterminate length
I think the optionality is supposed to be indicated by the three trailing dots . I admit to doing a double-take on this during my initial review, similar to David's question. It's optional for a server, sure, but it's never optional for a request just wrong. I agree that separate diagrams would help, at the minor cost of some page space.
Code change:
For example, <del> A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings.  Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings. </del> A server tests whether a content-coding for a given representation is acceptable using these rules:

Related discussion:
text: (alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.
Code change:
2.1.2. <del> The "match-dest" value of the Use-As-Dictionary header is a sf-string value that provides a request destination (https://fetch.spec.whatwg.org/#concept-request-destination). </del> <ins> The "match-dest" value of the Use-As-Dictionary header is an inner list of sf-string values that provides a list of request destinations for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination). </ins> <del> An empty string for "match-dest" MUST match all destinations. </del> <ins> An empty list for "match-dest" MUST match all destinations. </ins> <del> For clients that do not support request destinations or if the value of "match-dest" is a value that is not supported by the client then the client MUST treat it as an empty string and match all destinations. </del> <ins> For clients that do not support request destinations, the client MUST treat it as an empty list and match all destinations. </ins> <del> The "match-dest" value is optional and defaults to the empty string. </del> <ins> The "match-dest" value is optional and defaults to an empty list. </ins> 2.1.3.

Related discussion:
text: This changes the field to be a list of destination strings to allow for matching multiple destinations (i.e. document and frame). This allows for matching an empty destination explicitly using an empty string. e.g.
NAME could you PTAL and see if this looks OK for the destination matching?
The spec of compression dictionary transport says: But an empty "" is used for some features such as , , , , , Cache API, Download, prefetch and prerender. (See this ). So currently there is no way to set up a dictionary for such destinations. For example, I want to use a dictionary for fetch() API, but I don't want to use the dictionary for HTML documents. NAME How about using a string "empty" for such empty destination? We are already using "empty" for header of empty destination request. URL Also if we don't need to use an empty string "" for , I think should be a instead of a . We don't need to use double quotes.
Having special values feels a bit strange, particularly since it's only defined in the internal processing part of the w3c spec. If we use a list of strings we can use for an explicit empty destination and use an empty list for matching everything (and as the default). Does that seem reasonable?
OK, sounds reasonable. Thanks.
option was introduced in the Compression Dictionary Transport spec by . But if my understanding is correct, currently it is not allowed to setting multiple types of destinations. So if I want to use a dictionary for HTML files including top frame, and , I need to download the dictionary three times. NAME How about allowing setting multiple types of destinations? Example:
Sounds good (though document/frame is probably the only practical use case). I'll switch it to an inner-list of tokens.
lgtm Sorry for the late reply.
Code change:
control window is set to the default initial window size until a WINDOW_UPDATE frame is received. <del> A </del> <ins> In addition to changing the flow control window for streams that are not yet active, a </ins> <del> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </del> <ins> frame can alter the initial flow control window size for streams with active flow control windows (that is, streams in the "open" or "half closed (remote)" state).  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Related discussion:
text: Thanks for the PR NAME Should we move the issue discussion (URL) to this PR?
LGTM
NAME if you have comments, please let me know ASAP.
Merged by RFC editor.
has the following text: Draft 17 added the changed to . Can someone clarify why would streams in other states be excluded?
Those are the only states in which data (or DATA) can be sent.
Does your stream have to be eligible for data to be sent to have its windows manipulated? For example are IDLE streams intentionally excluded? Would this mean that the initial settings frame wouldn't apply to any streams? I think it may make sense to be able to alter window sizes of streams in other states because of dependencies/priorities and how the windows are distributed amongst the tree.
While it is true than an idle stream is affected, the text there is to highlight the fact that streams with active flow control windows (i.e., ones that might be in use) might be affected.
Is it possible to clarify this? I think there are a few options: If we are going to explicitly call out states: we should call out all states where it could possibly impact streams. If we are not going to explicitly call out states: Use a description which implies stream state which is defined elsewhere in the spec. Something like: Note this is just an example... The current text in the specification is in conflict with this clarification you have provided in this issue. It seems like the following sentence in the spec may be sufficient by itself?
NAME - Ping.
The inclusion of stream state in your clerical response leads me to another question related to the priority tree, stream state, and flow control windows. indicates that . The flow control window is a resource which can be divided amongst nodes in the priority tree. However the frame can be sent/received in all states, but the frame is more restrictive in its allowed states. This discrepancy makes controlling the resource (the window) difficult (i.e. providing a mechanism to avoid deadlock). Is there any way to clarify or allow the resource (the window) to be controlled adequately along with priority?
As far as it goes, yes, a server might allocate flow control window based on priority. But that only applies to the logic that an implementation uses to decide how to allocate credit to flow control windows, which is intentionally (and expressly) unspecified.
Code change:
control window is set to the default initial window size until a WINDOW_UPDATE frame is received. <del> A </del> <ins> In addition to changing the flow control window for streams that are not yet active, a </ins> <del> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </del> <ins> frame can alter the initial flow control window size for streams with active flow control windows (that is, streams in the "open" or "half closed (remote)" state).  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Related discussion:
text: I don't think that it needs a special call-out.
I agree that it doesn't need to be specifically called out that the window can be treated as a resource, and that this is an implantation detail. However calling out the stream states when referencing frames that impact the flow control window may be overly restrictive. For example the are not the only states in which a stream may be in the priority tree. Here are what I believe to be the relevant portions of the specification which relate to flow control window and stream state. seems to be very careful about stream state and doesn't necessarily limit to just is much more restrictive and declares that is not allowed in , or . For there is special mention that these frames must be ignored, or may be an error (if it arrives ). If the clarifications in this issue are applied then it seems like the impact on the flow control windows is further limited to .
BTW, I consider the state associated with having a stream in the priority tree to be necessarily separate from the state that is maintained for an "active stream" (i.e., one with active send or receive state). Lumping them all together exposes you to some potential attacks.
Can you be more specific (particularly about the )? I guess what I'm after is two fold: Consistency amongst the sections that discuss window update and stream state. Not necessarily preventing window_update being controlled when a stream is in the priority tree, or rational as to why it makes sense to do so.
The amount of state you commit to a stream that is active is potentially large (flow control windows, primarily). That is strictly bounded though by your value of the MAXCONCURRENTSTREAMS setting. If that state has to live on the same lifetime as stream priority, then it is not covered by the setting and you are potentially in a position to commit a much larger amount of state. You can (obviously) manage this by careful management of the transition to and from the active states, but I believe that it is better to instead have separate tracking of priority.
One way to implement this cleanly is to have a (small) priority state for streams that is created and managed by a garbage-collector. Active stream state can be a separate object that maintains a reference to the priority state (that might be nullable, or you could require that only closed or idle streams be exposed to the GC).
Code change:
control window is set to the default initial window size until a WINDOW_UPDATE frame is received. <del> A </del> <ins> In addition to changing the flow control window for streams that are not yet active, a </ins> <del> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </del> <ins> frame can alter the initial flow control window size for streams with active flow control windows (that is, streams in the "open" or "half closed (remote)" state).  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Related discussion:
text: I think we are straying into implementation details a bit, and we are in agreement that the state could be managed, but in the scope of this issue....I re-read your PR and I am fine with it :)
NAME Does "old value" here means the old initial window size?
Yes
Code change:
The PRIORITY frame does not define any flags. <del> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> The PRIORITY frame always identifies a stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </ins> .

Related discussion:
text: Two issues were raised about the use of the words "existing" and "current" to refer to streams. These were a little squishy, so I tightened the language a little. The text no longer uses either word to refer to streams, instead using stream states to describe where the relevant text applies and favouring "identified" as a fallback.
uses some under specified termonlogy: For example is for a PRIORITY frame which can be sent/received in the any state the same as in the following contexts: Can be translated to the stream's state? For example does it roughly mean ? If so then the usage in the PRIORITY frame section is a bit more confusing because a PRIORITY frame could be the first valid frame sent/received for a stream.
NAME - Thanks for the clarification!
NAME - I do have a question regarding your clarifications to the SETTING frame (specifically the SETTINGSINITIALWINDOWSIZE portion). It seems a bit confusing if a PRIORITY frame has been exchanged on an IDLE stream for the SETTINGSINITIALWINDOWSIZE not to apply to it. Consider the following example: 1) Stream is in the state (no frames exchanged) 2) A PRIORITY frame for stream is received. 3) A SETTINGS frame is received to update SETTINGSINITIALWINDOW_SIZE. ... 4) Stream transitions into the state. Is seems a bit counter intuitive that stream 's window will be the window size prior to step 3. Just imagine there are many more SETTINGS frames exchanged (and other events) before step URL stream 's window will be even more difficult to understand how it got to where it is.
That's a fair point. The current text is: From this, you might infer that a reserved or idle stream isn't affected. Implicit in here is that you don't actually have an active flow control window until streams are in those states. There is no sense in performing any accounting until you are actually sending, right? But then, it's only accounting and that 32-bit number might be allocated and used in some implementations. So, I think that this can be clarified, rather than rely on people only accounting in those states, the text might be better saying: Does that make more sense?
This does make more sense. On a related URL is the rational to prohibit WINDOWUPDATES on the IDLE streams when PRIORITY frames have been exchanged?
Code change:
The PRIORITY frame does not define any flags. <del> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> The PRIORITY frame always identifies a stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </ins> .

Related discussion:
text: It seems like if a stream is allowed to be put into the priority tree (via a PRIORITY message) and its window size controllable (via SETTINGS) then why would a WINDOWUPDATE also not be allowed? I look to the following statement and think that accounting may already be required to track the PRIORITY and SETTINGS updates. The WINDOW_UPDATE accounting seems like it is very similar (or may be close to identical depending on the implementation).
We want to strictly limit the amount of state that is maintained for non-open streams. Currently, that is limited to priority. Opening that to more state isn't really necessary. For WINDOWUPDATE, there is only the case where you want to open the flow control window immediately after opening a stream, which currently causes a potential stall on the remote/sender side. As specified, you can create a priority graph that is separate from the other stream state (flow control in particular). If we allowed WINDOWUPDATE in idle (or reserved), then you need to commit more state. We already acknowledge that priority information needs special handling outside of the key stream states, so the risk is both accounted for, and already present. The most important factor though is that priority is expendable. Under DoS, you can drop priority on the floor. You can't do the same for flow control. Therefore, any state commitment needs to be strictly bounded for that.
Right. So for these cases the peer creating the stream will have to wait to expand (or shrink) the window until after the stream has transitioned out of the IDLE state. So state may not be required however if a peer wants to change the window for that stream then state will be necessary to keep and act upon when the state transition occurs. I"m not sure I follow. WINDOW_UPDATE is allowed in reserved according to . Priority is an interesting portion of the spec. It almost seems like you could ignore priority all together and be compliant :)
Hmm, strange how you forget these things. Yes, you can send WINDOWUPDATE in "reserved (remote)". This allows a client to affect the flow control window of the server that has promised a push. This is something that I know Firefox uses so that it can resume stalled pushes when it knows that they are needed. No extra credits over the initial window size are given to pushed streams until they are recognized as necessary.
Code change:
The PRIORITY frame does not define any flags. <del> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> The PRIORITY frame always identifies a stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </ins> .

Related discussion:
text: You can't send WINDOWUPDATE in "reserved (local)". After all, the other side (the client) won't be sending anything on that stream. So none of this really affects processing of the setting :)
I think I agree with you in general (it is not necessary). I agree that minimizing state on IDLE streams seems like more of a driving force, and I also recognize that the peer can wait to send WINDOW_UPDATES until transitioning out of IDLE. I can also imaging a scenario that if an endpoint puts the node into a priority tree, it is possible they have an estimate of what they are going to be sending. It may then follow the theme of "a more flexible expressions of priority" (from ) to also be able to control the window of those streams (at a finer granularity than the SETTINGS frame). Anyways thanks for the discussion and clarification.
Editorial problem, I hope: The spec uses the phrase "current stream" in two places (both related to PRIORITY), but without any definition of what that means: 1) "5.1 Stream States: ... half closed (local) ... PRIORITY frames received in this state are used to reprioritize streams that depend on the current stream." 2) "6.3 Priority ... Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream." I don't have alternate wording proposals because I'm not exactly sure what those sentences are trying to say. Note that I'm only talking about "current stream" in the singular. I see no confusion with the use of "current streams" (plural) in "6.9.2 Initial Flow Control Window Size".
"subject stream" or "identified stream" would work effectively well. I'll take suggestions.
Both sound fine, but "identified stream" is already used often in the spec and "subject stream" is never used.
Excuse me for trolling this issue but I couldn't help but notice how evil the issue number is.
Code change:
the Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments.  The abstract specifies <del> environments where the Quick- Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment is not recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick- Start method is discussed as an example in RFC9049. </del> <ins> environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment is not recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. </ins> Strictly speaking, Informational RFCs in the IETF stream need not meet all of the criteria in this document, as they do not carry a

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
then the ULA prefix that is numerically lowest should be kept, and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <ins> 6.5. In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: </ins>

Related discussion:
text: I added a section about services provided by the Stub Network. This will need some more work, but it seems useful to have, and it now says that DHCPv6 is generally NOT RECOMMENDED but is permitted, and MUST be off by default.
(Based on recent discussion in v6ops) We don't specify yet the type of hosts on the IPv6 stub network in detail. For example, an IoT device host only needs an address which it can configure with SLAAC based on the /64 on-mesh/on-link prefix. However, there could also be more complex hosts in principle that need their own prefixes (e.g. /64) delegated to it for internal usage and they may like to use their DHCPv6-PD client for that. For example for running multiple virtual machines / dockers inside the host where these VMs are on their own virtual network segment. I expect these cases to be out of scope and there's no requirement on the stub router to do either DHCPv6-PD server or relay role. Do we need to make this explicit in a goal / non-goal / out-of-scope section ?
With my AD hat one, I sincerely hope to keep the stub network with simple devices, else the SNAC WG will try to make a simple problem too complex ;-) Without any hat, I do not mind having an applicability statement with non-goals in it.