jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
text: between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency. <del> 5.3. The "APP" message contains arbitrary contents.  This is useful for metadata that would otherwise have to be shoved into the media bitstream. Relays MUST NOT differentiate between streams containing "SEGMENT" and "APP" frames.  The same forwarding and caching behavior applies to both as specified in the"HEADERS" frame. 5.4. </del> <ins> 5.2. </ins> The "GOAWAY" message is sent by the server to force the client to reconnect.  This is useful for server maintenance or reassignments
Code change:
This case seems easily avoidable by a subscriber, so the simplest option is to close the session.
Draft 04 currently doesn't mention about sending any response when the SUBSCRIBE_UPDATE is successful or when it fails even though the draft hints on possible failures The above suggests that an error should be sent to inform the client that it is making invalid subscription updates.
documents some other aspects of SUBSCRIBE_UPDATE that are underspecified.
Table 4 is missing SUBSCRIBEUPDATE, so there's no code for this message type. Section 6.5 doesn't say what to do when the update is malformed, in some way. SUBSCRIBEERROR? Is a bogus SUBSCRIBE_UPDATE ignored, or does it nuke the original subscribe?
One nit, but LGTMLGTM

Related discussion:
text: guarantee that a publisher will not have already sent Objects before the new start Object.  The end Object MUST NOT increase and when it decreases, there is no guarantee that a publisher will not have <del> already sent Objects after the new end Object. </del> <ins> already sent Objects after the new end Object.  A publisher SHOULD close the Session as a 'Protocol Violation' if the SUBSCRIBE_UPDATE violates either rule or if the subscriber specifies a Subscribe ID that does not exist within the Session. </ins> Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to be delivered multiple times.  Like SUBSCRIBE, EndGroup and
Code change:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Related discussion:
text: of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given <del> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. </del> <ins> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.  If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription.  The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track
Code change:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Related discussion:
text: Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription <del> aggregation allows relays to make only a single forward subscription for the track.  The published content received from the forward </del> <ins> aggregation allows relays to make only a single upstream subscription for the track.  The published content received from the upstream </ins> subscription request is cached and shared among the pending subscribers.
Code change:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Related discussion:
text: parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. <ins> 6.1.1.2. The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference. If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD always specify the value received from an upstream subscription when there is one, and nothing otherwise.  If an earlier Object arrives later than subsequent Objects, relays can consider the receipt time as that of the next later Object, with the assumption that the Object's data was reordered. If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay that intends to serve multiple subscriptions for the same track. Publishers SHOULD consider whether the entire Object is likely to be delivered before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information. </ins> 6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages
Code change:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Related discussion:
text: Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del> <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).
Code change:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Related discussion:
text: largest Group ID for this track.  This field is only present if ContentExists has a value of 1. <ins> Subscribe Parameters: The parameters are defined in version- specific-params. </ins> 6.13. A publisher sends a SUBSCRIBE_ERROR control message in response to a
Code change:
This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM

Related discussion:
text: preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. <del> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </del> <ins> An "OBJECT_STREAM" message carries a single object on a stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </ins> An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object".
Code change:
This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM

Related discussion:
text: Other fields: As described in canonical-object-fields. An "OBJECT_DATAGRAM" message carries a single object in a datagram. <del> There is no explicit length of the payload; it is determined by the length of the datagram. </del> An Object received in an "OBJECT_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram".  To send an Object with "Object
Code change:
This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM

Related discussion:
text: of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given <del> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. </del> <ins> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.  If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription.  The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track
Code change:
This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM

Related discussion:
text: Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription <del> aggregation allows relays to make only a single forward subscription for the track.  The published content received from the forward </del> <ins> aggregation allows relays to make only a single upstream subscription for the track.  The published content received from the upstream </ins> subscription request is cached and shared among the pending subscribers.
Code change:
There are some obsolete references to Object Send Order, and part of the STREAMHEADERTRACK description seems to have slipped below the header for the following section.
Thanks for fixing these .. LGTM

Related discussion:
text: When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> "Object Send Order" specified in the stream header. </del> <ins> "Publisher Priority" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".
Code change:
There are some obsolete references to Object Send Order, and part of the STREAMHEADERTRACK description seems to have slipped below the header for the following section.
Thanks for fixing these .. LGTM

Related discussion:
text: When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the "Object Send Order" specified in </del> <ins> All objects on the stream have the "Publisher Priority" specified in </ins> the stream header. All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". To send an Object with "Object Forwarding Preference" = "Group", find <del> the open stream that is associated with the subscription, "Group ID" and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </del> <ins> the open stream that is associated with the subscription and "Group ID", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </ins> The Object Status field is only sent if the Object Payload Length is zero.
Code change:
I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments

Related discussion:
text: specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. <del> 2.3.2. </del> <ins> 2.4.2. </ins> Each track MAY have one or more associated connection URLs specifying network hosts through which a track may be accessed.  The syntax of
Code change:
I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments

Related discussion:
text: priority in every stream or datagram header.  As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a property of the Track and the <del> Objects it contains.  In both cases, a lower value indicates a higher </del> <ins> Peeps it contains.  In both cases, a lower value indicates a higher </ins> priority, with 0 being the highest priority. The Subscriber Priority is considered first when selecting a