jiebi/CodeConvo huggingface dataset:
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. <del> The Track Namespace and Track Name identified by the Track Alias is different from the one specified in the subscription identified by </del> <ins> If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by </ins> Subscribe ID, the receiver MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. <ins> An "OBJECT_PREFER_DATAGRAM" message carries a single object in a datagram or a stream.  There is no explicit length of the payload; it is determined by the length of the datagram or stream.  If this message appears on a stream, it MUST be the only message on a unidirectional stream. An Object received in an "OBJECT_PREFER_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram". To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload, and compare the length with the maximum datagram size of the session.  If the object size is less than or equal maximum datagram size, send the serialized data as a datagram.  Otherwise, open a stream, send the serialized data and terminate the stream.  An implementation SHOULD NOT send an Object with "Object Forwarding Preference" = "Datagram" on a stream if it is possible to send it as a datagram. </ins> 6.3.3. When multiple objects are sent on a stream, the stream begins with a
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

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> same "Object Send Order". </del> <ins> "Object Send Order" 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:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields. <ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID within a given group on that stream. </ins> 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 same "Object Send Order". </del> <ins> All objects on the stream have the "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. <ins> A sender MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. </ins> 6.3.4. Sending a track on one stream:
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the <del> subscription it MAY send a SUBSCRIBE_ERROR with code TBD.  A publisher MUST NOT send objects from outside the requested start and end. </del> <ins> subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'. A publisher MUST NOT send objects from outside the requested start and end. </ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: Reason Phrase: Provides the reason for subscription error. <del> Track Alias: When Error Code is TBD, the subscriber SHOULD re- issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session-termination).  TODO: Add a registry for subscribe error codes and make this field conditional. </del> <ins> Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session- termination). </ins> 6.7.
Code change:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Related discussion:
text: This document uses the conventions detailed in (RFC9000) when describing the binary encoding. <del> This document also defines an additional field type for binary data: </del> <ins> As a quick reference, the following list provides a non normative summary of the parts of RFC9000 field syntax that are used in this specification. This document extends the RFC9000 syntax and with the additional field types: To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value. </ins> 2.
Code change:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Related discussion:
text: The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. <del> 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. </del> <ins> model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An Object can become unavailable, but it's contents MUST NOT change over time. 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.
Code change:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Related discussion:
text: 6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> 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
Code change:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Related discussion:
text: Subscribe ID: Subscription Identifer as defined in message- subscribe-req. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed. <ins> ContentExists: 1 if an object has been published on this track, 0 if not. If 0, then the Largest Group ID and Largest Object ID fields will not be present. Largest Group ID: the largest Group ID available for this track. This Group ID corresponds to the Group that would be returned with a subscribe-locations RelativePrevious value of 0.  This field is only present if ContentExists has a value of 1. Largest Object ID: the largest Object ID available within the largest Group ID for this track.  This Object ID corresponds to the Object that would be returned with a subscribe-locations RelativePrevious value of 0. This field is only present if ContentExists has a value of 1. </ins> 6.6. A publisher sends a SUBSCRIBE_ERROR control message in response to a
Code change:
This PR
Track namespace and track name properties were removed from SUBSCRIBEOK message in draft 02. But they are still part of the text under "6.5. SUBSCRIBEOK" which is confusing.

Related discussion:
text: Subscribe ID: Subscription Identifer as defined in message- subscribe-req. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed.
Code change:
Regardless of where they're retrieved from and over time.
I put a two very small nit comments but don't care either way. They do not change the substance of the PR and +1 on the overall thing this is saying.
This came as part of interim at Denver when discussing multiple announce for same track. There needs to text that mandates, if 2 objects comes with same name, they need to be bit identical. Also needs to clarify on how long the name needs to be unique

Related discussion:
text: The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. <del> 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. </del> <ins> model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An Object can become unavailable, but it's contents MUST NOT change over time. 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.
Code change:
QUIC uses RESET, we should too.
Teeechnically, QUIC uses STOP for receiver-initiated closes. But RESET is better than RST.

Related discussion:
text: dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application
Code change:
QUIC uses RESET, we should too.
Teeechnically, QUIC uses STOP for receiver-initiated closes. But RESET is better than RST.

Related discussion:
text: 6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.
Code change:
Since they're on different streams, an object can arrive before its SUBSCRIBEOK. This is easy to process because the Subscribe ID and Track Alias must have been the ones that the subscriber chose. What if the publisher then sends a SUBSCRIBEERROR? Is this valid behavior or an error? (If it weren't for the Expires field, SUBSCRIBE_OK would be entirely redundant and we could get rid of it.)
Individual Comment: This is covered a bit in and Luke expressed a desire to document the full state machine in . My read is that you can't send objects before SUBSCRIBE OK (but they can arrive out of order). I don't think you can send SUBSCRIBEERROR after SUBSCRIBEOK (objects or no objects), instead, use SUBSCRIBE_RST?
I agree that SUBSCRIBEERROR cannot follow SUBSCRIBEOK. I think you're saying that if Objects are in flight, then SUBSCRIBEOK must be as well, so a SUBSCRIBEERROR would in itself be an error. That sounds reasonable to me.
We're clear that only one of SUBSCRIBEOK or SUBSCRIBEERROR can be sent: the subscription, via SUBSCRIBEOK ({{message-subscribe-ok}}) or the SUBSCRIBEERROR {{message-subscribe-error}} control message. The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either SUBSCRIBEOK or SUBSCRIBEERROR. I wrote to clarify that you can't send objects and a SUBSCRIBE_ERROR.

Related discussion:
text: track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). <ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application specific information.
Code change:
by adding an explicit bool indicating whether any Objects were published for a subscription, similar to the explicit bool added to SUBSCRIBE_OK in .
and define: However, what happens if no objects were ever produced/sent?
Individual Comment: Oops. Two possible ways to handle this: 1) Flag indicating presence of these fields (Use Location now that is defined elsewhere?) 2) Change the semantics of the fields to be exclusive (eg: it is the first object NOT sent), so 0/0 means none.
I'm inclined towards 0/0, because optional fields are more complex to parse and I would expect the existing logic to work correctly with 0/0.
Let's say the last object delivered by the relay is . Does the relay send RESET or ? Is the subscriber able to infer the presence of future objects? What if either of those objects actually exist in the cache?
Individual Comment: If we use exclusive encoding then I'd say that the receiver shouldn't infer the existence of non-existence of the named object, and either 5/30 or 6/0 works, but 5/30 is preferable?
If you define there will be no objects greater than or equal to these, then 0/0 makes total sense. So 0/0 for null case and say the last group ID of the last object publish was 10 then the value in SUB_FIN would be 11.
In we went with an explicit flag, so I'm inclined to do the same here for consistency.

Related discussion:
text: Subscribe ID: Subscription identifier as defined in message- subscribe-req. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.
Code change:
by adding an explicit bool indicating whether any Objects were published for a subscription, similar to the explicit bool added to SUBSCRIBE_OK in .
and define: However, what happens if no objects were ever produced/sent?
Individual Comment: Oops. Two possible ways to handle this: 1) Flag indicating presence of these fields (Use Location now that is defined elsewhere?) 2) Change the semantics of the fields to be exclusive (eg: it is the first object NOT sent), so 0/0 means none.
I'm inclined towards 0/0, because optional fields are more complex to parse and I would expect the existing logic to work correctly with 0/0.
Let's say the last object delivered by the relay is . Does the relay send RESET or ? Is the subscriber able to infer the presence of future objects? What if either of those objects actually exist in the cache?
Individual Comment: If we use exclusive encoding then I'd say that the receiver shouldn't infer the existence of non-existence of the named object, and either 5/30 or 6/0 works, but 5/30 is preferable?
If you define there will be no objects greater than or equal to these, then 0/0 makes total sense. So 0/0 for null case and say the last group ID of the last object publish was 10 then the value in SUB_FIN would be 11.
In we went with an explicit flag, so I'm inclined to do the same here for consistency.

Related discussion:
text: Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.