jiebi/CodeConvo huggingface dataset:
Code change:
The format of SUBSCRIBE is as follows: <del> Subscribe ID: The subscription identifier that is unique within the session.  "Subscribe ID" is a monotonically increasing variable length integer which MUST not be reused within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR messages. </del> <ins> Subscribe ID: The subscriber specified identifier used to manage a subscription.  "Subscribe ID" is a variable length integer that MUST be unique and monotonically increasing within a session and MUST be less than the session's Maximum Subscribe ID. </ins> Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object),

Related discussion:
text: Some diffs are due to me reflowing text to fit the line limits, so please ignore those. Once we have this and a limit on announce IDs, it seems likely that we'll be able to get rid of 'Role', but for now it can stay.
Thanks NAME . this looks like a good improvement. I have few clarification questions and bit of extra work for you to add some informative text, if my comment seems ok to you.
Unfortunately, that makes it much more difficult for the server to tell abusive clients from valid ones, as we discovered with the recent HTTP/2 rapid reset attacks. In the end we did develop heuristics, but they're imperfect and in the process we broke a bunch of applications in an effort to defend against DDoS attacks. In contrast, QUIC had a system like this and experienced no issues and we didn't need to develop any new heuristics.
Currently, there's no way to limit the number of simultaneous subscriptions. QUIC stream limits cannot effectively be used to limit the number of subscriptions, so I'd suggest MoQ have a limit. The simplest idea would be to have a limit specified as a parameter in the server's SETUP message. As a related question, even with limits, what happens if a client subscribes to a number of streams that it doesn't have the bandwidth to support? ie: 10 4k video streams and they're on a slow link? Possibly the subscriptions could fail with an error code indicating that the server didn't have enough bandwidth to request them and/or serve them to the client?
rofl I just came here to post the same issue. See: URL I think we follow QUIC and have a MAXSUBSCRIBES frame. The initial value can be set in the SETUP message. The subscribe is considered active until the publisher sends or (TODO). I think we're okay with the subscriber/publisher using arbitrary subscription IDs if there's a single control channel. It would be easier if we required incremental subscribe IDs and you couldn't reuse them though.
Also do we need ? That seems like a potential attack vector too, since it involves inserting into a potentially CDN-wide routing table.
Code change:
The format of SUBSCRIBE is as follows: <del> Subscribe ID: The subscription identifier that is unique within the session.  "Subscribe ID" is a monotonically increasing variable length integer which MUST not be reused within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR messages. </del> <ins> Subscribe ID: The subscriber specified identifier used to manage a subscription.  "Subscribe ID" is a variable length integer that MUST be unique and monotonically increasing within a session and MUST be less than the session's Maximum Subscribe ID. </ins> Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object),

Related discussion:
text: A few months ago, I would have said we should go with the HTTP/2 style design of just having a limit on number of streams, but given the recent issues, I'd be inclined towards the QUIC style of specifying the max number. But I think that works better if we also have a subscription ID that's monotonically increasing for subscriptions, ie: Announces also likely need some limits, but I'm less clear on how that might work.
I propose a monotonically increasing in the message. You can't reuse Subscribe IDs. We add a message containing the maximum allowed ID and possibly a SETUP parameter to set the initial value. The corresponding messages use that ID instead of echoing the full track name. This removes ambiguity and overhead. We would still have Track ID for compressing the full track name (maybe renamed?). You could have multiple SUBSCRIBE reference the same Track ID but contain different Subscribe IDs. For example: Same for .
Adding a Subscribe ID used as you're describing SGTM and as you said remove any ambiguity about what subscription is being referenced. Unless we are absolutely never going to have multiple subscriptions, I believe we'll need a Subscribe ID.
This is related to
may be better to name it as transaction_id . since it is id tied to a given subscribe transaction ..
As a follow-up to adding a Subscribe ID, we'll add a SETUP field or param to indicate the initial value and a MAXSUBSCRIBEID frame to increase the limit, similar to QUIC flow control.
The consensus at the session today was to go with a QUIC style approach, so I wrote There was interest in a similar approach for announces, but announces don't yet have an ID, so that will have to wait.
Will assign to Mike English
This seems like a really complicated way to limit the subscribes. I understand how it mirror streams but that had pretty different constrains. Why don't we just have an subscribe error of "too many subscriptions"? Discussed open issues in the 7 August 2024 virtual, not recorded here. Remaining issue (just do a SUBSCRIBE_ERROR?) went to the list and chairs declared rough consensus, although at least 2 participants would prefer not to have this.
Code change:
the dependencies is assumed to match that of the track declaring the dependencies. <del> 3.2.19. </del> <ins> 3.2.20. </ins> A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing with higher temporal fidelity. <del> 3.2.20. </del> <ins> 3.2.21. </ins> A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing with higher fidelity. <del> 3.2.21. </del> <ins> 3.2.22. </ins> A string defining the codec used to encode the track.  For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of WEBCODECS-CODEC-REGISTRY.  For CMAF packaged content, the string codec registrations are defined in XXX. <del> 3.2.22. </del> <ins> 3.2.23. </ins> A string defining the mime type MIME of the track.  This parameter is typically supplied with CMAF packaged content. <del> 3.2.23. </del> <ins> 3.2.24. </ins> A number defining the framerate of the track, expressed as frames per second. <del> 3.2.24. </del> <ins> 3.2.25. </ins> A number defining the bitrate of track, expressed in bits second. <del> 3.2.25. </del> <ins> 3.2.26. </ins> A number expressing the encoded width of the track content in pixels. <del> 3.2.26. </del> <ins> 3.2.27. </ins> A number expressing the encoded height of the video frames in pixels. <del> 3.2.27. </del> <ins> 3.2.28. </ins> The number of audio frame samples per second.  This property SHOULD only accompany audio codecs. <del> 3.2.28. </del> <ins> 3.2.29. </ins> A string specifying the audio channel configuration.  This property SHOULD only accompany audio codecs.  A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. <del> 3.2.29. </del> <ins> 3.2.30. </ins> A number expressing the intended display width of the track content in pixels. <del> 3.2.30. </del> <ins> 3.2.31. </ins> A number expressing the intended display height of the track content in pixels. <del> 3.2.31. </del> <ins> 3.2.32. </ins> A string defining the dominant language of the track.  The string MUST be one of the standard Tags for Identifying Languages as defined

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
3.2. <del> A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: </del> <ins> A request or response that is constructed without encoding a known length for each section uses the format shown in format- indeterminate-length: </ins> <del> That is, an indeterminate-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. </del> <ins> An indeterminate-length request consists of a framing indicator (framing), request control data (request-control), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding. </ins> <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del> <ins> An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) and response control data (response-control). </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be

Related discussion:
text: Arguably a technical change, though as it is in a picture, so I want to highlight it. This is on top of , so just look at 5468983321b104de62b1aae8df8963ad1abd5fa9 if you want to see the "technical" change.
Code change:
received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). <ins> A recipient MUST ignore the If-Unmodified-Since header field if the resource does not have a modification date available. </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

Related discussion:
text: From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).
Code change:
. <ins> 10.5.1. A large HeaderBlock can cause an implementation to commit a large amount of state.  In servers and intermediaries, header fields that are critical to routing, such as ":authority", ":path", and ":scheme" are not guaranteed to be present early in the header block.  In particular, values that are in the reference set cannot be emitted until the header block ends. This can prevent streaming of the header fields to their ultimate destination, and forces the endpoint to buffer the entire header block.  Since there is no hard limit to the size of a header block, an endpoint could be forced to exhaust available memory. A server that receives a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code RFC6585.  A client can discard responses that it cannot process. The header block MUST be processed to ensure a consistent connection state, unless the connection is closed. </ins> 10.6. HTTP/2 enables greater use of compression for both header fields

Related discussion:
text: A proposed explanation for what to do with large header blocks.
Discussed in NYC; this can be considered editorial.
Code change:
Here is a gzip-compressed json object <ins> Request: </ins> Now the same payload body conveys a malformed json object. <ins> Request: </ins> A Range-Request alters the payload body, conveying a partial representation. <ins> Request: Response: </ins> Now the method too alters the payload body. <ins> Request: Response: </ins> 3. Digest algorithm values are used to indicate a specific digest

Related discussion:
text: Fixes artwork formatting.
[x] requests and responses to use different artworks [x] artworks not containing trailing/heading carriages
Code change:
5. <del> The security considerations of HTTP caching I-D.ietf-httpbis-cache apply. </del> <ins> The security considerations of HTTP caching HTTP-CACHING apply. </ins> The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different

Related discussion:
text: This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.
Code change:
statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is considered safe for use on the Internet.  Each published algorithm is <del> also required to include a statement in the abstract describing </del> <ins> also REQUIRED to include a statement in the abstract describing </ins> environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorithm is deemed safe for use, but it is still is not recommended for use

Related discussion:
text: required -> REQUIRED
I agree with this change. The use of REQUIRED/RECOMMENDED for process rather than SHOULD/MUST for protocol, is not entirely consistent, but I think it is fine and unambiguous. Please do merge
Code change:
2. <del> In HTTP/1.1, a client is permitted to send an "Upgrade" request header field (RFC9110) to indicate that it would like to use this connection for a protocol other than HTTP/1.1.  The server replies with a "101 (Switching Protocols)" status code if it accepts the protocol change.  However, that specification also permits the server to reject the upgrade request: </del> <ins> In HTTP/1.1, a single connection is often used for many requests, one after another.  After each request, the connection is returned to its initial state, ready to send more HTTP requests.  However, HTTP/1.1 also contains two mechanisms that allow the client to change the protocol used for the remainder of the connection. </ins> <del> This rejection of the upgrade is common, and can happen for a variety of reasons: </del> <ins> One such mechanism is the "Upgrade" request header field (RFC9110), which indicates that the client would like to use this connection for a protocol other than HTTP/1.1.  The server replies with a "101 (Switching Protocols)" status code if it accepts the protocol change. The other mechanism is the HTTP "CONNECT" method.  This method indicates that the client wishes to establish a TCP connection to the specified host and port.  The server replies with a 2xx (Successful) response to indicate that the request was accepted and a TCP connection was established.  After this point, the TCP connection is acting as a TCP tunnel, not an HTTP/1.1 connection. Both of these mechanisms also permit the server to reject the request.  For example, RFC9110 says: and Rejections are common, and can happen for a variety of reasons.  An "upgrade" request might be rejected if: </ins> The server does not support any of the client's indicated Upgrade Tokens (i.e., the client's proposed new protocols), so it

Related discussion:
text: This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME
Code change:
This document specifies a data integrity mechanism that protects HTTP "representation data" or content, but not HTTP header and trailer <del> fields, from certain kinds of accidental corruption. </del> <ins> fields, from certain kinds of corruption. </ins> Digest fields are not intended to be a general protection against malicious tampering with HTTP messages.  This can be achieved by

Related discussion:
text: Spotted another mention of accidental while I was at it, so changed that too.
From NAME WGLC review: Corruption could also be non-accidental. Let's remove the accidental qualifier or add words about explicit manipulation (for good or bad purposes).
Agree, but I think that accidental/bad implementation has to be mentioned. See URL iirc there were some comments regarding the fact that Digest alone (eg. without other mechanisms) is not enough to protect against malicious agents... NAME do you remember anything on that? The current text imho is correct, since it adds:
NAME NAME I'd close with no-action :)
NAME Removing "accidental" from the sentence in question would fix the issue.
I completely agree, I'll do that!
LGTM
Code change:
The result of the gZIP compression is then base64url-encoded, as defined in Section 2 of RFC7515. <ins> 4.2. The following rules apply to validating a Referenced Token in JWT representation, which references a Status List Token.  Application of additional restrictions and policy are at the discretion of the verifying party. The JWT MUST contain an "iss" (issuer) claim that contains a unique string identifier for the entity that issued the JWT.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the referenced Status List Token. The JWT MUST contain an "status" (status) claim conforming to the rules outlined in The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4.2.1. The following rules apply to validating the "status" (status) claim The claim value MUST be a valid JSON object. The claim value object MUST contain an "idx" (index) member with a numeric value that represents the index to check for status information in the Status List for the current JWT.  The value of this member MUST be a non-negative number, containing a value of zero or greater. The claim value object MUST contain a "uri" member with a string value that identifies the Status List containing the status information for the JWT.  The value of this member MUST be a uri conforming to RFC3986. </ins> 5. This document defines potential statuses of Referenced Tokens as

Related discussion:
text: reorder section on Referenced Token and Status List Token URL
I did a first review of this draft. As a newbie to the topic, I found the following issues: I miss a description of the fundamental concept, i.e. the status list itself is a JWT (issued by the same issuer issuing the JWTs), the status list JWT is obtained from a URL hosted by that issuer or another party, the link between the JWT and its status list is provided through data in the JWT. I suggest to add this in the Introduction (or an Overview) section. When reading Section 3.1. for the first time I was confused whether it describes the status list JWT or the JWT referring to the status list. I think it is the latter and it should be clear to the reader on first sight. I think the order of definition should be changed. Right now, I'm supposed to understand how a status list JWT is used in a JWT without even knowing what that status list JWT is. I suggest to change order: 1) Overview of the concepts, 2) specify status list JWT (structure and where/how to obtain), 3) embedding in a JWT (syntax, processing rules, ...).
Agree on 1+2. As mentioned in we need a better word describing the "Token" that is being described by the status List. I will make a PR using "Subject Token" as this comprises both JSON and CBOR formats. Agree on 3 as well.
For reordering it would make sense to get forward with the existing PRs first and do it afterwards..
Addressing some of these issues in
What's left to do: reorder Status List Token first and Referenced Token afterwards
Code change:
to be deployed without fear that they will be blindly forwarded by older intermediaries. <del> Furthermore, intermediaries SHOULD remove or replace field(s) whose semantics are known to require removal before forwarding, whether or not they appear as a Connection option, after applying those fields' </del> <ins> Furthermore, intermediaries SHOULD remove or replace fields that are known to require removal before forwarding, whether or not they appear as a connection-option, after applying those fields' </ins> semantics.  This includes but is not limited to: <del> The Connection header field's value has the following grammar: Connection options are case-insensitive. </del> A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content.  For example,

Related discussion:
text: The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.
Code change:
The HTTP pseudo-method CONNECT (HTTP-p2) is used to convert an HTTP/1.1 connection into a tunnel to a remote host.  CONNECT is <del> primarily used with HTTP proxies to established a TLS session with a </del> <ins> primarily used with HTTP proxies to establish a TLS session with a </ins> server for the purposes of interacting with "https" resources. In HTTP/2.0, the CONNECT method is used to establish a tunnel over a

Related discussion:
text: The sentence in 8.3: "CONNECT is primarily used with HTTP proxies to established a TLS session with a server for the purposes of interacting with https resources." ... does not read. I believe it should be: "CONNECT is primarily used with HTTP proxies to establish a TLS session with a server for the purposes of interacting with https resources." This pull request fixes this incredibly minor issue.