jiebi/CodeConvo huggingface dataset:
Code change:
optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track. <del> 3.2.9. </del> <ins> 3.2.10. </ins> A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace. <del> 3.2.10. </del> <ins> 3.2.11. </ins> A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values <del> 3.2.11. </del> <ins> 3.2.12. </ins> Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is an

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
Code change:
nodes, links and termination points inside a network, relationships between instances belonging to different networks, links to functional data for the instances, including <del> configuration, health, symptoms.  :The data can be historical, real-time, or future data for 'what-if' scenarios. </del> <ins> configuration, health, symptoms. The data can be historical, real-time, or future data for 'what- if' scenarios. </ins> 3.

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
11.7. <del> This document registers the "h2c" upgrade token in the "HTTP Upgrade Tokens" registry (HTTP). </del> <ins> Previous versions of this document (RFC7540) registered an upgrade token.  This capability has been removed: see versioning. </ins>

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
interruptions.  The client can offer the server to upgrade such a request to a resumable upload (see feature-detection) by adding the "Upload-Complete: ?1" header field to the original request.  The <del> request is not changed otherwise. </del> <ins> "Upload-Length" header field SHOULD be added if the upload's final size is known upfront.  The request is not changed otherwise. </ins> A server that supports resumable uploads at the target URI can create a resumable upload resource and send its upload URL in a "104 (Upload

Related discussion:
text: Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.
Code change:
interruptions.  The client can offer the server to upgrade such a request to a resumable upload (see feature-detection) by adding the "Upload-Complete: ?1" header field to the original request.  The <del> request is not changed otherwise. </del> <ins> "Upload-Length" header field SHOULD be added if the upload's final size is known upfront.  The request is not changed otherwise. </ins> A server that supports resumable uploads at the target URI can create a resumable upload resource and send its upload URL in a "104 (Upload

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
3.2. <ins> Caches are required to update a stored response's header fields from another (typically newer) response in several situations; for example, see combining.responses, freshening.responses and head.effects. When doing so, the cache MUST add each header field in the provided response to the stored response, replacing field values that are already present, with the following exceptions: In some cases, caches (especially in user agents) store processed representations of the received response, rather than the response itself, and updating header fields that affect that processing can result in inconsistent behavior and security issues.  Caches in this situation MAY omit these header fields from updating stored representations on an exceptional basis, but SHOULD limit such omission to those fields necessary to assure integrity of the stored representation. For example, a browser might store a response's body after removing content-codings, thereby making its metadata inaccurate.  Updating that stored metadata with a different Content-Encoding header field would be problematic.  Likewise, a browser might store a post-parse tree representation of HTML, rather than the body received in the response; updating the Content-Type header field would not be workable in this case, because any assumptions about the format made in parsing would now be invalid. Furthermore, some fields are automatically processed and removed by the HTTP implementation; for example, the Content-Range header field. Implementations MAY automatically omit such header fields from updates, even when the processing does not actually occur. Note that the Content-* prefix is not a signal that a header field is omitted from update; it is a convention for MIME header fields, not HTTP. 3.3. </ins> If the request method is GET, the response status code is , and the entire response header section has been received, a cache

Related discussion:
text: Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.
Code change:
this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.4. </del> <ins> 7.5. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this

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:
If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences. <del> 2.2.3. </del> <ins> 3.2.1. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate

Related discussion:
text: NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!
Code change:
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition as per evaluation prior to performing the

Related discussion:
text: evaluating false on a duplicate change request sending 2xx without validator for reasons unknown.
Hmm, of course, now I found another related message in my archives that prompted me to remember why the requirement was added. I should probably rewrite the paragraph (without that requirement) and describe the edge case as a note.
RFC7232 in URL has the following clause: It doesn't really explain what security or performance considerations are leading to such a requirement, but it calls for a lot of infrastructure and design work to implement it because that logic can be implemented only if the server is stateful. The stateless server cannot comply with such a requirement. See related mail list thread: URL Either RFC should explain why such logic MUST be implemented or relax "MUST" into "SHOULD" in that clause or remove that clause completely.
Should I submit an errata proposing to remove the following clause from RFC 7232, section 3.1: " In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent" It seems like nobody can recall/explain why this clause is there.
I finally found the original commit 303b82b12a53c170f6f755aaaf8840ac1240aa77
And the discussion motivating the change is under . Certainly the intent was to remove the constraint that an error be sent when a duplicate request is made, so the extra limitations were to reduce edge cases.
It is not an errata. This is the right place to discuss it and either find a better wording or strike the text.
Thanks, NAME for finding the original commit and your response! Sending response for repeating requests makes total sense. My issue is about a sub-condition of response that is stated in the RFC7232. In the original commit that you referenced that sub-condition is stated as: I think I understand the original recommendation not to send back. It would be better to replace with there though. But in RFC7232 that sub-condition clause is changed to: The reason of not sending with back is not explained in RFC7232 and nobody can remember why it is there or explain this requirement. Complying with this requires dev effort and extra infra since we would need to track immediate previous requests from each agent.
Code change:
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition as per evaluation prior to performing the

Related discussion:
text: Our API servers are light-weight and stateless so this is a huge requirement for us. Instead, we would prefer a way simpler approach of always sending back along with responses, but we need to comply with RFC7232 thus this discussion. So, the proposal is to do one of the following (preferred) Remove the following clause from RFC7232: (If aforementioned clause is kept) Explain the reason of not sending in that sub-condition (at least) Change to in that clause.
These requirements were motivated by a tiny edge case related to protecting partial updates after two clients simultaneously try a PUT. However, I can't remember if it was when one succeeds and one fails, or one or both responses are lost and they try again, or something like that, nor can I remember what difference was made by not sending ETag. Hence, I intend to remove the requirement as being too obscure to implement in a testable way.
Code change:
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition as per evaluation prior to performing the

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
3.3. <del> A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </del> <ins> 3.3.1. Ordinary HTTP headers apply only to the single resource identified in the request or response.  An origin-scoped HTTP header is a special response header that is intended to change the client's behavior for subsequent requests to any resource on this origin. Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an unambiguous origin of its own.  Origin-scoped headers apply to this origin when they are associated with a templated TCP proxy response. Here are some origin-scoped headers that could potentially be sent by a templated TCP proxy: "Alt-Svc" "Strict-Transport-Security" "Public-Key-Pins" "Accept-CH" "Set-Cookie" RFC6265, which has configurable scope. "Clear-Site-Data" 3.3.2. Authentication to a templated TCP proxy normally uses ordinary HTTP authentication via the "401 (Unauthorized)" response code, the "WWW- Authenticate" response header field, and the "Authorization" request header field (RFC9110).  A templated TCP proxy does not use the "407 (Proxy Authentication Required)" response code and related header fields (RFC9110) because they do not traverse HTTP gateways (see operational-considerations). Clients SHOULD assume that all proxy resources generated by a single template share a protection space (i.e., a realm) (RFC9110).  For many authentication schemes, this will allow the client to avoid waiting for a "401 (Unauthorized)" response before each new connection through the proxy. </ins> 4.

Related discussion:
text: However, I'm happy to say that "WWW-Authenticate" is the winner here, and "Proxy-Authenticate" does not traverse "connect-tcp" (or "connect-udp") gateways.
Looks good! :+1:
Code change:
. <ins> A SETTINGS frame with a length other than a multiple of 6 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.5.1. The payload of a SETTINGS frame consists of zero or more parameters,

Related discussion:
text: If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?