jiebi/CodeConvo huggingface dataset:
Code change:
Name: zstd-d <del> Description: A stream of bytes compressed using the Zstandard protocol with an external dictionary of not more than 8 MB. </del> <ins> Description: "Dictionary-Compressed Zstandard" data format. </ins> Reference: This document Notes: <del> 4.2. </del> <ins> 6.2. </ins> IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (HTTP) according to the table below: <del> 5. </del> <ins> 7. </ins> To minimize the risk of middle-boxes incorrectly processing dictionary-compressed responses, compression dictionary transport MUST only be used in secure contexts (HTTPS). <del> 6. </del> <ins> 8. </ins> The security considerations for Brotli RFC7932 and Zstandard RFC8878 apply to the dictionary-based versions of the respective algorithms. <del> 6.1. </del> <ins> 8.1. </ins> The dictionary must be treated with the same security precautions as the content, because a change to the dictionary can result in a

Related discussion:
text: And if the new resource is really much larger than the old one, the benefits of delta compression are dubious anyway. So the suggestion is to authorize a window size which is slightly larger than the external dictionary size. As to how much larger exactly, a suggestion here is by +25% (x1.25). I would expect a large majority of update scenarios to fit into this picture, with the new resource being slightly larger than the old one by a few %. For the less common cases where the new ressource is much larger than the old one, Zstandard could still employ the dictionary but only for the beginning of decompression. The compression process will have to select a window size which remains under the specified limit (x1.25 external dictionary size). As a technical insight, note that byte-accurate window size is only a thing when the window is the entire decompressed content. Otherwise, the window size is encoded in a condensed format, which can only represent increments by 1/8th of a power of 2. This is not a problem to determine this "largest window size under the specified limit", but due to limited accuracy, you can already guess what would be the problem is we were to keep the formulation "not more than the larger of 8 MB and the size of the dictionary". Imagine that the external dictionary size is bytes, and the new resource to delta-compress is , aka 1-byte larger than the dictionary. With the initial formulation, since the window size is limited to the size of the dictionary, the compressor cannot use as a window size, because it's 1 byte larger than the limit. So, it will have to find the next best window size under the limit. Due to granularity limitations, this next best window size is 8 MB. So delta compression would proceed fine for the first 8 MB, but for the last 1 MB, data would have to be compressed without the benefit of the dictionary. With the newly proposed limitation to "x1.25 the dictionary size", delta compression would remain active in above scenario during the entire decompression process. And it would remain fully active if the new resource to decompress is 10 MB, 11 MB or 11.24 MB.
Code change:
Name: zstd-d <del> Description: A stream of bytes compressed using the Zstandard protocol with an external dictionary of not more than 8 MB. </del> <ins> Description: "Dictionary-Compressed Zstandard" data format. </ins> Reference: This document Notes: <del> 4.2. </del> <ins> 6.2. </ins> IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (HTTP) according to the table below: <del> 5. </del> <ins> 7. </ins> To minimize the risk of middle-boxes incorrectly processing dictionary-compressed responses, compression dictionary transport MUST only be used in secure contexts (HTTPS). <del> 6. </del> <ins> 8. </ins> The security considerations for Brotli RFC7932 and Zstandard RFC8878 apply to the dictionary-based versions of the respective algorithms. <del> 6.1. </del> <ins> 8.1. </ins> The dictionary must be treated with the same security precautions as the content, because a change to the dictionary can result in a

Related discussion:
text: Consequently, by the time the payload to compress reaches 1 MB, it should already contain all references it needs to compress the rest of the file. I would not expect a large impact of the custom dictionary beyond that point, let alone beyond 8 MB. The plan would be for the library to do this adaptation automatically. The user would not have to know anything about it, though it's better if the user understands that the library selects the closest window size which is <= to the limit, so that they are not surprised if, upon inspection, the final window size is not byte-identical to the set limit. A good API documentation will likely help to reach this objective If by implementors you mean "server side programmers", they would have to know what's the implicit window size limit when a client requests a format (essentially the rule you are currently defining). Then they would set this limit as a compression parameter, and the library will take care of the adaptation into window size.
Yes. (Keeping in mind of course that most traffic in question will presumably be under the 8 MB floor and so none of this complexity will apply.) Right now the zstd library has limited controls about setting detailed window constraints. We'll need to add a new option to give users that fine-grained control. We can do that with an eye towards user simplicity. Frankly, I'm also very open to also adding a flag (and equivalent compression parameter in the library) that would just look at the size of the dictionary (which zstd necessarily has access to) and would configure the window accordingly. In that case, users wouldn't have to do any math at all.
OK, I chaged the structure and language so that they are no longer streams of bytes compressed with a given algorithm but are now specifically and . The references for those named formats have the window restrictions (which for Zstandard includes the 1.25x dictionary requirement). Currently the byte stream itself is still a native Brotli/Zstandard stream, just with specific settings but this also makes it cleaner if we decide to . PR with the update is here: URL
lgtm with nits, thank you!LGTM!
Code change:
Some algorithms, although registered, have since been found vulnerable: the MD5 algorithm MUST NOT be used due to collision <del> attacks CMU-836068 and the SHA algorithm is NOT RECOMMENDED due to collision attacks IACR-2019-459. </del> <ins> attacks CMU-836068 and the SHA algorithm MUST NOT be used due to collision attacks IACR-2020-014. </ins>

Related discussion:
text: Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm
Code change:
A consequence of this record structure is that range requests RFC7233 and random access to encrypted payload bodies are possible at the granularity of the record size.  However, without data from adjacent <del> ranges, partial records cannot be used.  Thus, it is best if records start and end on multiples of the record size, plus the 16 octet authentication tag size. </del> <ins> ranges, partial records cannot be used.  Thus, it is best if range requests start and end on multiples of the record size, plus the 16 octet authentication tag size. </ins> 3.

Related discussion:
text: "The record starts and ends on multiples of the record size" sounds like a tautology.
Code change:
In some cases, it is valuable to allow "connect-tcp" clients to reach "connect-tcp"-only proxies when using a legacy configuration method <del> that cannot convey a URI template.  To support this arrangement, </del> <ins> that cannot convey a URI Template.  To support this arrangement, </ins> clients SHOULD treat certain errors during classic HTTP CONNECT as indications that the proxy might only support "connect-tcp":

Related discussion:
text: Changes: s/tcpport/targetport/ (aligning with connect-udp) Remove support for multiple IPs and
NAME The discussion at IETF 119 leaned toward removing the multiple-IP mode entirely. Are you suggesting that we should keep it?
This PR contains two changes; I'm not making a suggestion with regard to multiple-IP mode, but I think aligning the variable names in the template makes sense. Did both get dropped, or is that being discarded because it's in the same PR?
OK, I've updated this PR to also drop the multiple-IP support entirely.
The target_host variable is only described vaguely. It should be defined more rigorously. For example, it doesn't specify whether IPv6 scope IDs are allowed or not. I'd recommend reusing the text from RFC 9298.
OK, I've opened to make the definition more rigorous.
Fixed by
The draft currently defines the "targethost" and "tcpport" variables. We should replace "tcpport" with "targetport" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.
The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in , the client can use a single template for various purposes by inspecting the variables that it contains: "targetport" -> connect-udp "tcpport" -> connect-tcp "ipproto" -> connect-ip "dns" -> DoH Using the same name ("targetport") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori_ whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.
What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).
OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto").
Code change:
In some cases, it is valuable to allow "connect-tcp" clients to reach "connect-tcp"-only proxies when using a legacy configuration method <del> that cannot convey a URI template.  To support this arrangement, </del> <ins> that cannot convey a URI Template.  To support this arrangement, </ins> clients SHOULD treat certain errors during classic HTTP CONNECT as indications that the proxy might only support "connect-tcp":

Related discussion:
text: It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119
Code change:
: The authorization server performing the assertion flow MAY leverage claims from the presented authorization grant and include <del> it in the access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </del> <ins> them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </ins> The representation of transcribed claims and their format is not defined in this specification.

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
This document introduces no new security considerations beyond those discussed in RFC8878. <ins> Note that decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received. </ins> 5. 5.1.

Related discussion:
text: Fixes URL
NAME could you take a look?
Comment by NAME This is rather unimportant, but I just wanted to mention it in case the authors find it useful. Feel free to ignore. The document states that there are no new security considerations, but that's perhaps not quite true. I think it might be useful to call out that an implementation cannot rely on its peer behaving correctly, so implementers will have to take into account they may still receive oversized frames from misbehaving clients. This is arguably no different from the situation today, so it can be argued that the current considerations are accurate. I just thought it might be useful to call it out so some engineer doesn't remove validation checks since the other side is supposed to behave now. Just because we have standards, doesn't mean that everyone complies.
RFC8878 says in its security considerations: Perhaps we could add something like: "Decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received." NAME Thoughts?
We could do something explicit like that, yeah. But I'm partial to just broadening the existing statement a little: This seems sufficient to me because this issue is called out explicitly in para 4 there (URL). What do you think, NAME NAME
Don't have strong opinions, but I think maybe adding a sentence explicitly about the window size limit is good, given the document is specifically about enforcing the window size limit. This will ensure nobody misses it even if they don't click through the reference to RFC8878.
Code change:
2. <ins> MoQT has a hierarchical object model for data, comprised of objects, groups and tracks. </ins> 2.1. <del> The basic element of MoQTransport is an </del> <ins> The basic data element of MoQTransport is an </ins> .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and <del> potential dependencies. model-group Objects carry associated metadata such as priority, TTL, or other information usable by a relay, but relays MUST treat the object payload as opaque. The application is solely responsible for the contents of objects. This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> potential dependencies. model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2. A <del> is collection of objects, part of a larger track (model-track). A group behaves as a join point for subscriptions.  A new subscriber may not want to receive the entire track, and will instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. The application is responsible for how objects are placed into groups.  In general, objects within a group SHOULD NOT depend on objects in other groups. </del> <ins> is a collection of objects and is a sub-unit of a track (model- track).  Objects within a group SHOULD NOT depend on objects in other groups.  A group behaves as a join point for subscriptions.  A new subscriber might not want to receive the entire track, and may instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. </ins> 2.3. A <del> is a sequence of objects (model-object) organized into groups (model- group).  A subscriber can request individual tracks at group boundaries, including any new objects while the track is active. </del> <ins> is a sequence of groups (model-group).  It is the entity against which a consumer issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the producer while the track is active. </ins> 2.3.1.

Related discussion:
text: NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM
Code change:
Paths can also present a variable delay as described in delay. <del> 7.5. </del> <ins> 7.6. </ins> A proposed congestion control algorithm SHOULD explore how the algorithm performs with non-compliant senders, receivers, or routers.

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:
7. <del> The "Save-Data" request header field is a token that indicates client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </del> <ins> The "Save-Data" request header field consists of one or more tokens that indicate client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode

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:
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the <del> track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). </del> <ins> track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: Into SUBSCRIBEDONE. I didn't remove the SUBSCRIBEERROR message in favor of SUBSCRIBE_CLOSED as NAME suggested in this PR. Addresses some comments in , but possibly not all
So my notes from this discussion. CLOSE is confusing with QUIC layer. People seemed to prefer UNSUBSCRIBE over SUBSCRIBE_CLOSE. I love the move aware from RST and FIN as naming.
Propose names from my understanding of discussion call Announce (send by publisher) , AnnouceOK, AnnouceError UnAnnounce (send by publisher) UnAnnounceOK, UnAnnounceError AnnouceEnd ( sent by thing that received Annouce) , AnnouceEndOK, AnnouceEndOK Subscribe (send by subscriber) , SubscribeOK, SubscribeError UnSubscribe (send by subscriber) , SubscribeOK, SubscribeError SubscribeEnd (send by thing that received subscriber), SubscribeOK, SubscribeError Mostly trying to get rid of FIN / RST and have different names for the messages that flow in opposite directions.
I don't like the name of the different messages used to terminate. I'd rather have one message that transitions to the terminal state, with an optional error code and final group/object. IMO the subscription flow: And the ANNOUNCE flow mirrors: The brackets mean a message is optional. The sender is responsible for creating and the receiver is responsible for closing, possibly at the bequest of the sender (like QUIC's STOP_SENDING).
has been merged, adding yet another term (CANCEL), but I figured we'd clean that up with this issue.
Since we are bikeshedding, I prefer ANNOUNCE_RESCIND instead of CANCEL, since an announce is more of a declarative statement than an active request from the sender.
Heh and UNANNOUNCE and UNSUBSCRIBE stick out because they don't share the same prefix.
I like the names being proposed as they help make make is easier to understand. I do want to separate out one issue. The STOP / CLOSE type thing happens way after the initial SUBSCRIBE thus it can end up in a situation where auth has expired or something else has gone wrong this I like the current design that allows an OK or ERROR to be returned for those. I think it is also key for sender of the things stoping the subscribe to know that the other side has acted on that so we need the OK.