jiebi/CodeConvo huggingface dataset:
Code change:
GOAWAY frame, the identified stream is the highest numbered stream initiated by the client. <ins> Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </ins> If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those streams are not or will not be processed.  The receiver of the GOAWAY

Related discussion:
text: After some sleep, I've read through the section and noticed a few other minor inconsistencies. This alters the structure slightly, as well as replacing the first sentence with a more accurate one. Supercedes . .
+1, thanks
LGTM
Merged by RFC editor.
We are working on a HTTP/2 library and we are a bit confused and we would like to get it right. Is it correct that after a sender sent a frame with some to a receiver, the sender may still open new streams, even with stream identifiers higher than the sent in the frame? That is the frame and the only limit the ability of the receiver? If this is correct, and I believe it is, then I find the following sentence in the first paragraph at confusing. In my opinion it should say something of the like Thanks.
I am also intersted in getting clarity on this topic. It seems what the "spirit" of the is something like: Each endpoint maintains the goaway last stream id from its peer. When a goaway is received then no local streams can be created (i.e. streams can only transition to ), and all local streams with > from the goaway frame are closed (or as the spec says ). Remote streams can still be opened, and to ensure a graceful connection shutdown a goaway frame should be sent in response.
Not quite: Upon receipt of GOAWAY, new streams can be created, but with the following restrictions: those with stream identifiers higher than the will be ignored. Those with stream identifiers lower or equal are subject to the usual risk of loss, but they might be processed. Success is determined by what happens on the stream, of course.
NAME - Can you clarify the following from : This is what lead me to believe that streams can not be "created" after receiving a ?
Hmm. I'd forgotten that. That is in conflict with the graceful shutdown we've specified. I think that we need to take this to the list. This seems like a genuine bug.
Thanks for the quick response NAME Would you prefer to bring the issue to the list?
I'm just trying to formulate something.
hmm I see NAME As a follow up, does the in the GOAWAY have to be the identifier of a stream that actually exists or could it also just be a "random number"?
Code change:
GOAWAY frame, the identified stream is the highest numbered stream initiated by the client. <ins> Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </ins> If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those streams are not or will not be processed.  The receiver of the GOAWAY

Related discussion:
text: The intent was to say that the receiver of a GOAWAY can't create new streams higher than the value in GOAWAY. Let me check back in tomorrow; maybe fresh eyes will add perspective.
So the intention of the change is allow receiver of GOAWAY are still allowed to create stream lower or equal to received last-stream-id, accepting the fact that those streams are ignored by peer? As the graceful shutdown process as described in draft 17, server first sending GOAWAY with (2^31) - 1 starts to ignore any new streams created by peer and after some time (this ensures that GOAWAY is reached to the client), server sends another GOAWAY with updated last-stream-id where processing has occurred already.
NAME the intent of the change is to not change anything :) The process has been unclear, but the point is that if you receive GOAWAY with a last-stream-id greater than anything you have initiated, you can use what space remains for new streams. What that means is that you can issue new requests on that connection while you take the time to create a replacement connection. This was considered critical for . That means that 2^31-1 serves only as a warning of impending closure, though in theory it need not change any behaviour for the existing connection. I'd take steps to make a replacement connection though.
Thank you for clarification!
Here is a link to NAME doc from the mailing list which provides additional clarity to this issue URL
Latest PR is much more comfortable to me. Thanks!
Code change:
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del> <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del> <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del> <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del> <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it

Related discussion:
text: HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!
Code change:
3. <del> The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the specific query format media types that may be used. </del> <ins> The "Accept-Query" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used. </ins> <del> The Accept-Search header field specifies a comma-separated listing of </del> <ins> The Accept-Query header field specifies a comma-separated listing of </ins> media types (with optional parameters) as defined by RFCHTTP. <del> The order of types listed by the Accept-Search header field is </del> <ins> The order of types listed by the Accept-Query header field is </ins> insignificant. 4.

Related discussion:
text: (opening this so it has a discussion venue) Currently, the spec uses "SEARCH" (for the reasons given in the spec). Alternatives: 1) pick a new name 2) use GET with payload (probably unrealistic, just listed for completeness) 3) use POST and find a way to label it as safe 4) re-use another existing safe method that takes a body (PROPFIND, REPORT) (just listed for completeness) The obvious drawback in "pick a new name" is the forseealke bike-shedding.
Just my .02. Using is initially attractive because it's familiar; effectively we'd be extending the semantics of the method with a header. However, I'm not sure it's a good idea. implies certain guarantees to clients, servers and intermediaries -- e.g., write-through. If an extension can change those guarantees, it's important that they're visible to all components, and an extension (e.g., a header) by nature can't guarantee that. It seems to me that one of the critical things to do is to get a positive indication from the user agent that the request they're sending doesn't have write-through, so a extension would need to carry an indication from the client. However, the origin server is also likely to need to convey a cache key and perhaps additional information, which leads this approach to something that's looking complex; the client has to send a certain header, the server has to send a certain header, and an intermediary still might not understand what's going on (which might be good or bad). So that makes me lean towards the status quo, (1), or (4) as being more straightforward. Reusing an already-deployed name has been discussed elsewhere; I'm not convinced that it's going to add a lot of value, considering that most traffic is HTTPS now and so intermediaries with fixed lists of supported methods are much less common. If we had data that they'd get through e.g., an enterprise virus scanning proxy whereas a new method wouldn't, I'd be interested to see that. Still, if fits the bill adequately, I think it's fine. The real test will be whether folks (especially HTTP API developers) find it compelling enough to use; I'm not sure quite gets there, but it's in the ballpark. If we're going to consider new names, I'd suggest .
Code change:
3. <del> The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the specific query format media types that may be used. </del> <ins> The "Accept-Query" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used. </ins> <del> The Accept-Search header field specifies a comma-separated listing of </del> <ins> The Accept-Query header field specifies a comma-separated listing of </ins> media types (with optional parameters) as defined by RFCHTTP. <del> The order of types listed by the Accept-Search header field is </del> <ins> The order of types listed by the Accept-Query header field is </ins> insignificant. 4.

Related discussion:
text: If the point of this exercise is to make safe-ness visible to intermediaries, then a method is the right place to put that signal. I'm comfortable enough with , though an entirely name would be equally good. (I think that we should continue discussion about cache keys separately.)
I value a lot the ability for intermediaries to filter out write requests before they reach an application. Reusing won't have this advantage.
Interim discussion: switch document to use , which has good support from the attendees, and see how it seems to people who would be adopting.
Que? This is far more than the simple rename I was expecting. I had a similar double-take on first read, but most of the additional changes appear to be excising the WebDAV references, which is reasonable to do along with the rename.
Code change:
Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on <del> the wire" is dependent on other transformations (e.g. transfer </del> <ins> the wire" is dependent on other transformations (e.g., transfer </ins> codings for HTTP/1.1 - see RFC9112).  To help illustrate HTTP representation concepts, several examples are provided in resource- representation.

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass
Code change:
certificate are not already available, they will need to be sent as described in cert-available as part of this exchange. <ins> If the client does not have the desired certificate, it instead sends an Empty Authenticator, as described in Section 5 of I-D.ietf-tls- exported-authenticator, in a "CERTIFICATE" frame in response to the request, followed by a "USE_CERTIFICATE" frame which references the Empty Authenticator.  In this case, or if the client has not advertised support for HTTP-layer certificates, the server processes the request based solely on the certificate provided during the TLS handshake, if any.  This might result in an error response via HTTP, such as a status code 403 (Not Authorized). </ins> 3. The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are

Related discussion:
text: Follow-on to ; in the process of fixing this, I noticed that I'd added a "server" header but missed adding a corresponding "client" header, so the client discussion appeared in the server section.
For some reason, that seems to be endemic in this doc. Let's do that cleanup separately.
I appreciate the addition of the section heading. Though Section Headings Use Title Case.
Code change:
2.1.5. <ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary- ID" request header when the dictionary is advertised as being available. The server identifier MUST be treated as an opaque string by the client. The server identifier MUST NOT be relied upon by the server to guarantee the contents of the dictionary.  The dictionary hash MUST be validated before use. The "id" value string length (after any decoding) supports up to 1024 characters. The "id" value is optional. 2.1.6. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!
Code change:
The ROLE parameter is mandatory for the client.  All of the other parameters are optional. <del> 6.1.1.1. </del> <ins> 6.1.2.1. </ins> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
The ROLE parameter is mandatory for the client.  All of the other parameters are optional. <del> 6.1.1.1. </del> <ins> 6.1.2.1. </ins> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
For example: <del> When a client receives Accept-CH, it SHOULD append the Client Hint header fields that match the advertised field-values.  For example, based on Accept-CH example above, the client would append DPR, Width, Viewport-Width, and Downlink header fields to all subsequent requests. </del> <ins> When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it SHOULD append the Client-Hint header fields that match the advertised field-values to the header list of all subsequent requests.  For example, based on Accept-CH example above, a user agent could append DPR, Width, Viewport-Width, and Downlink header fields to all subresource requests initiated by the page constructed from the response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </ins> 2.2.2. When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to emit a <del> Vary response header field (RFC7234) to indicate which hints were used and whether the selected response is appropriate for a later request. </del> <ins> Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Above example indicates that the cache key needs to include the DPR header field.

Related discussion:
text: WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL
Code change:
(CDNs).  Additionally, relays serve as policy enforcement points by validating subscribe and publish requests at the edge of a network. <ins> Relays are endpoints, which means they terminate Transport Sessions in order to have visibility of MoQ Object metadata. </ins> Relays can cache Objects, but are not required to. 5.1.

Related discussion:
text: My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM
Code change:
The "match-dest" value is optional and defaults to the empty string. <del> 2.1.4. </del> <ins> 2.1.3. </ins> The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
are used in support of other HTTP/2 features. Multiplexing of requests is achieved by having each HTTP request- <del> response exchanged assigned to a single StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request does not prevent progress on other requests. </del> <ins> response exchange associated with its own StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. </ins> Flow control and prioritization ensure that it is possible to <del> properly use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </del> <ins> efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </ins> StreamPriority ensures that limited resources can be directed to the <del> most important requests first. </del> <ins> most important streams first. </ins> HTTP/2 adds a new interaction mode, whereby a server can PushResources.  Server push allows a server to speculatively send a

Related discussion:
text: Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.