jiebi/CodeConvo huggingface dataset:
Code change:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 15. </del> <ins> 16. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may

Related discussion:
text: As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.
Code change:
6.2. <ins> Header field name: Accept-CH-Lifetime Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints 6.3. </ins> Header field name: Content-DPR Applicable protocol: HTTP Status: standard

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the <del> tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del> <ins> tokens it conveys statuses for.  The value MUST be computed using the algorithm described in jwt-status-list-claim-encoding. 3.2.2. Each status of a Referenced Token MUST be represented with a bit size of 1,2,4, or 8.  Therefore up to 2,4,16, or 256 statuses for a Referenced Token, depending on the bit-size, are possible.  This limitation is intended to limit bit manipulation necessary to a single byte for every operation and thus keeping implementations simpler and less error prone. The overall status list is encoded as a byte array.  Depending on the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified using an index that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. The complete byte array is compressed using gZIP RFC1952. The result of the gZIP compression is then encoded as base64 encoding as defined in Section 4 of RFC4648 and stored as a string. Example of a byte representing 8 statuses (1-bit status list) with indices 0,1,2,3,4,5,6,7 (1 byte): Example of a more complex status list of length 12 using 2 bit statuses (3 bytes): </ins> 3.3.

Related discussion:
text: Questions for the encoding: base64 vs url-safe base64 bitwise encoding right now is least significant bit to most significant bit The part describing the bit-encoding still needs be rewritten In general: I searched a bit for better ways to encode/compress but in terms of simplicity and support for different programming languages, it seems some form of byte array and gZIP seem to be a pretty decent pick.
I've made a first implementation in Kotlin today. To me, it feels very natural to count Byte indexes up from 0 to size(whether this is left to right or right to left feels a little philosophical) and Bit indexes from right to left.
Imho we need another iteration on the description of the bit encoding, most likely with some form of ASCII art. I would prefer to do that in another PR- what do you think?
Code change:
attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. <del> For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for standardization (either as Experimental or as Proposed Standard), one possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities.  This is particularly encouraged in order to ensure algorithm specifications are widely disseminated to facilitate further research.  Such an internet-draft could also be considered for publication as an Informational RFC, as a first step in the process towards standardization.  Such a document would be expected to carry an explicit warning against using the scheme in the global Internet. Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent Submissions via the RFC-Editor).  However, we would hope the guidelines in this document inform the IESG as they consider whether to add a note to such documents. </del> <ins> Though out of scope of this document, congestion controller proponents may also seek publication of an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In general, these proposals are expected to be less mature than ones that follow the procedures in this document.  Documentation of deployed congestion controllers that cannot be changed by IETF or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). </ins> 3.

Related discussion:
text: Sec 2 leans heavy on the dated example of Highspeed TCP and drives pretty much everything to Experimental "until such time that the community better understands the solution space." It says that experimental RFCs can either be those judged to be safe on the internet, or those intended for testbeds. At this point, we probably understand enough to allow proposals to go for Proposed Standard. The safe/testbed distinction also doesn't make sense -- we might want to standardize CCs for controlled environments, like DCTCP. This needs a complete rewrite. It wouldn't hurt for that rewrite to also note that the IRTF is another venue, non-normatively.
I think a rewrite would help, but I'm think that could be too radical - we still do have proposals that ought ton be EXP either until deployment experience; or until we can agree they are "safe" for more general use. That doesn't seem to be a problem to me, but we ought to allow PS also. I agree we ought to mention IRTF.
Code change:
parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.2. </del> <ins> 6.14.2. </ins> The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE"

Related discussion:
text: Delayed LGTM.
Section 5.1 of the draft says: For the second case above, I think it would be useful to have an explicit signal from the publisher to signal the end of the track. For the third case, the text seems to hint (via a section reference) that if the subscription abruptly terminates with an error, the publisher can send SUBSCRIBE ERROR, but that section says: The draft should clarify if this is allowed following a SUBSCRIBE OK. Also +1 to adding UNSUBSCRIBE ().
+1 we should allow sending a SUBSCRIBE ERROR after a SUBSCRIBE OK.
I was assuming that the catalog change would be the way a track end was indicated then the client would unsubscribe.
As an individual: This seems like a bit of a subtle signal and something more explicit using the Track ID would be preferable for me.
I tend to incline towards Catalog indicating the status the more i think of it. Catalog is source of truth for tracks. Having a catalog update that indicates the following Full Track Name lastobjectid field Also if the catalog is ending, since the producer is going away, then include another optional field finished or something These would be sufficient and a clear way to identify the status end to end.
I think putting the FIN group/sequence in the catalog is clean. It does prohibit relays from cleanly terminating a broadcast early or rewriting group/object sequences, but I think that's fine? However, the wrinkle is that a sender MAY choose to not transmit a group/object. While I don't think this is explicitly stated in the draft, it's a requirement given that relays can only cache data for a finite amount of time. The viewer could get stuck waiting for the FIN group/sequence as signaled in the catalog, even though it is not forthcoming as the relay did not receive the object or already evicted it from the cache.
As an individual: Having an explicit signal outside the catalog will make it easier for relays to clean up track related state. If a publisher is done with a track, they can update the catalog, but it will need to propagate to all subscribers, who in turn need to issue an unsubscribe. Only when all of them unsubscribe (which we still need) can a relay discard the entry in the forwarding table. If the publisher also sends an explicit signal closing off the track, the relay can immediately clean up the state.
We need few things.
Code change:
parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.2. </del> <ins> 6.14.2. </ins> The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE"

Related discussion:
text: Cease the announcement This is an explicit signal from the publisher that it is no longer interested in sending media for the announced tracks. This is sent to the relay to trigger subscription cancellation downstream and clean up local relay state. Terminate the Subscription On subscribe end signal, each receiving entity will forward downstream and clean up local state. If it is the consumer, it stop media pipeline and so on. Unsubscribe For subscribers to explicitly indicate that they are no longer interested in a given track , they will send I am happy to write up a small PR as proposal if we think the general direction is fine.
What is the difference between Cancel the subscription and Unsubscribe?
Unsubscribe is an explicit action from the subscriber and Cancel is the signal from the publisher. May be we should call it ` instead ? I see cancel can be misleading
Got it. Terminate is better than Cancel.
We already have for the publisher to immediately terminate a subscription with a code/reason, so we could reuse that. However, the problem is when the termination occurs. The end of a broadcast would look like: There's a race, as the can arrive before the last objects due to retransmits or congestion control, severing the subscription early. Ideally we wait for all outstanding objects to get delivered and then terminate the subscription. In QUIC terminology, we need a in addition to our existing . The difficult part is determining which objects are still outstanding.
Do we want to distinguish a normal end of subscription (due to EOF), and an unexpected end (due to, e.g., a downstream server crashing)? We do that normally in QUIC (fin vs reset), so it might make sense to do that here.
Image the case where we have A sending to R sending to B. B subscribes to R. A sends ANNOUNCE to R. R subscribes to A. At this point media is flowing from A to R to B. A temporary looses WIFI connectivity and reconnects over 5G with new IP. A sends an ANNOUNCE to R, R subscribes to the new A and perhaps tries to send an error to original ANNOUNCE and end subscribe but A will not get that as that QUIC connection is gone.
Code change:
parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.2. </del> <ins> 6.14.2. </ins> The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE"

Related discussion:
text: Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).
Code change:
parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.2. </del> <ins> 6.14.2. </ins> The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE"

Related discussion:
text: We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.
Code change:
The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Referenced Token. 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. </del> <ins> "iss": REQUIRED when also present in the Status List Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Referenced Token.  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. </ins> "status": REQUIRED.  The "status" (status) claim MUST specify a JSON Object that contains at least one reference to a status

Related discussion:
text: Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references
Code change:
the corresponding key, so binding authentication to requests would not provide much benefit in practice. <ins> Key material used for authentication in unprompted authentication, whether symmetric or asymmetric MUST NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. </ins> 8. 8.1.

Related discussion:
text: Fixes httpwg/http-extensions.
Please mark this PR as fixing the corresponding issue
From NAME on the :
The conservative thing to do here would be to insist that the key be unique to the protocol. We have domain separation in our outputs, so we don't need to worry about unprompted auth messages being used in cross-protocol attacks, but a different protocol (that doesn't use context strings) could possibly be induced to generate unprompted auth messages. We also need to worry about key compromise. Imagine a protocol that leaks the private / secret key, that shares a key with unprompted auth. This doesn't even need to be a bug, it could be a commit-before-reveal style protocol. (Obviously that's a pathological example, but it shows we can't assume composability with all protocols) If we want to do a formal analysis (which I do) I think we need to be conservative here.
SGTM
Code change:
4.5. <del> Warp encodes the delivery information for each stream via a "HEADERS" frame (headers).  This MUST be at the start of each stream so it is easy for a relay to parse. </del> <ins> Warp encodes the delivery information for a stream via SEGMENT headers (segment). </ins> A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case

Related discussion:
text: Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.