jiebi/CodeConvo huggingface dataset:
6.3. <del> A OBJECT message contains a range of contiguous bytes from from the </del> <ins> An OBJECT message contains a range of contiguous bytes from from the </ins> specified track, as well as associated metadata required to deliver, <del> cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is present.  When the message type is 0x02, the field is not present. </del> <ins> cache, and forward it. </ins> <del> The format of the OBJECT message is as follows: </del> <ins> 6.3.1. </ins> <del> Track Alias :The track identifier as specified in the SUBSCRIBE message message-subscribe-req. </del> <ins> A canonical MoQ Object has the following information: </ins> <del> Group ID : The object is a member of the indicated group ID model- </del> <ins> Track Namespace and Track Name: The track this object belongs to. Group ID: The object is a member of the indicated group ID model- </ins> group within the track. Object ID: The order of the object within the group.  The IDs
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.)
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.
of the Parameter Value field in bytes. Each parameter description will indicate the data type in the <del> Parameter Value field.  If the parameter value is a varint, but the self-encoded length of that varint does not match the Parameter Length field, the receiver MUST ignore the parameter using the value in the Parameter Length field. </del> <ins> Parameter Value field.  If a receiver understands a parameter type, and the parameter length implied by that type does not match the Parameter Length field, the receiver MUST terminate the session with error code 'Parameter Length Mismatch'. </ins> 6.1.1.
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and
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 first 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
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".
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".
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.
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
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
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
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
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.
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
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.
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.
WebTransport.  Both provide streams and datagrams with similar semantics (see I-D.ietf-webtrans-overview); thus, the main difference lies in how the servers are identified and how the connection is <del> established.  There is no definition of the protocol over other transports, such as TCP, and applications using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </del> <ins> established.  When using QUIC, datagrams MUST be supported via the [QUIC-DATAGRAM] extension, which is already a requirement for WebTransport over HTTP/3. There is no definition of the protocol over other transports, such as TCP, and applications using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </ins> 3.1.1.
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). 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
Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control message providing the result of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of <del> either ANNOUNCE_OK or ANNOUNCE_ERROR. </del> <ins> either ANNOUNCE_OK or ANNOUNCE_ERROR.  When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE. A subscriber indicates it will no longer route subscriptions for a namespace it previously responded ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use
Other fields: As described in canonical-object-fields. <del> 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". </del> <ins> An "OBJECT_DATAGRAM" message carries a single object in a datagram. There is no explicit length of the payload; it is determined by the length of the datagram. </ins> <del> 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. </del> <ins> An Object received in an "OBJECT_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 send the Object as datagram.  In certain scenarios where the object size can be larger than maximum datagram size for the session, the Object will be dropped. </ins> 6.3.3.
6.14. <ins> The subscriber sends an "ANNOUNCE_CANCEL" control message to indicate it will stop sending new subscriptions for tracks within the provided Track Namespace. If a publisher recieves new subscriptions for that namespace after receiving an ANNOUNCE_CANCEL, it SHOULD close the session as a 'Protocol Violation'. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.15. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact match on track namespace unless otherwise negotiated by the application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track
6.2.2.1. <del> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three possible values, which are of type varint: </del> <ins> The ROLE parameter (key 0x00) allows each endpoint to independently specify what funnctionality they support for the session.  It has three possible values, which are of type varint: </ins> <del> The client MUST send a ROLE parameter with one of the three values specified above.  The server MUST close the session if the ROLE parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application. </del> <ins> Both endpoints MUST send a ROLE parameter with one of the three values specified above.  Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values. </ins> 6.2.2.2.
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the <del> track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RESET (see message-subscribe-reset). </del> <ins> track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it
6.7. A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating <del> it is no longer interested in receiving media for the specified track. </del> <ins> it is no longer interested in receiving media for the specified track and Objects should stop being sent as soon as possible.  The publisher sends a SUBSCRIBE_DONE to acknowledge the unsubscribe was successful and indicate the final Object. </ins> The format of "UNSUBSCRIBE" is as follows:
6.8. <del> A publisher issues a "SUBSCRIBE_FIN" message to all subscribers indicating it is done publishing objects on the subscribed track. </del> <ins> A publisher issues a "SUBSCRIBE_DONE" message to indicate it is done publishing Objects for that subscription.  The Status Code indicates why the subscription ended, and whether it was an error. </ins> <del> The format of "SUBSCRIBE_FIN" is as follows: </del> <ins> The format of "SUBSCRIBE_DONE" is as follows: </ins> Subscribe ID: Subscription identifier as defined in message- subscribe-req. <del> 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. Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track. Final Object: The largest Object ID sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.9. A publisher issues a "SUBSCRIBE_RESET" message to all subscribers indicating there was an error publishing to the given track and subscription is terminated. The format of "SUBSCRIBE_RESET" is as follows: Subscribe ID: Subscription Identifier as defined in message- subscribe-req. Error Code: Identifies an integer error code for subscription failure. </del> <ins> Status Code: An integer status code indicating why the subscription ended. </ins> Reason Phrase: Provides the reason for subscription error.
subscribers for each track.  Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active <del> until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see message-subscribe-done). </del> <ins> until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see message-subscribe-done). </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it
subscribe-req. Expires: Time in milliseconds after which the subscription is no <del> longer valid.  A value of 0 indicates that the subscription stays active until it is explicitly unsubscribed. </del> <ins> longer valid.  A value of 0 indicates that the subscription does not expire or expires at an unknown time.  Expires is advisory and a subscription can end prior to the expiry time or last longer. </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