jiebi/CodeConvo huggingface dataset:
Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. <del> Object Delivery Order: An integer indicating the object delivery order (delivery-order). </del> <ins> Object Send Order: An integer indicating the object send order (send-order). </ins> Object Payload: The format depends on the track container (containers).  This is a media bitstream intended for the decoder
16.3. <del> The delivery order (delivery-order depends on the desired user experience during congestion: </del> <ins> The send order (send-order depends on the desired user experience during congestion: </ins> <del> if media should be skipped: delivery order = PTS </del> <ins> if media should be skipped: send order = PTS </ins> <del> if media should not be skipped: delivery order = -PTS </del> <ins> if media should not be skipped: send order = -PTS </ins> <del> if video should be skipped before audio: audio delivery order < video delivery order </del> <ins> if video should be skipped before audio: audio send order < video send order </ins> <del> The delivery order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </del> <ins> The send order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </ins> (unskippable).
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
2. <ins> MoQT has a hierarchical object model for data, comprised of objects, groups and tracks. </ins> 2.1. <del> The basic element of MoQTransport is an </del> <ins> The basic data element of MoQTransport is an </ins> .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and <del> potential dependencies. model-group Objects carry associated metadata such as priority, TTL, or other information usable by a relay, but relays MUST treat the object payload as opaque. The application is solely responsible for the contents of objects. 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> potential dependencies. 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. </ins> 2.2. A <del> is collection of objects, part of a larger track (model-track). A group behaves as a join point for subscriptions.  A new subscriber may not want to receive the entire track, and will instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. The application is responsible for how objects are placed into groups.  In general, objects within a group SHOULD NOT depend on objects in other groups. </del> <ins> is a collection of objects and is a sub-unit of a track (model- track).  Objects within a group SHOULD NOT depend on objects in other groups.  A group behaves as a join point for subscriptions.  A new subscriber might not want to receive the entire track, and may instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. </ins> 2.3. A <del> is a sequence of objects (model-object) organized into groups (model- group).  A subscriber can request individual tracks at group boundaries, including any new objects while the track is active. </del> <ins> is a sequence of groups (model-group).  It is the entity against which a consumer issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the producer while the track is active. </ins> 2.3.1.
specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached
The application MAY use any error message and SHOULD use a relevant code, as defined below: <del> Session Terminated No error occurred; however the endpoint wishes </del> <ins> Session Terminated: No error occurred; however the endpoint wishes </ins> to terminate the session. <del> Generic Error An unclassified error occurred. </del> <ins> Generic Error: An unclassified error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.
client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called <del> ; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </del> <ins> SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </ins> The wire format of the SETUP message is as follows:
The wire format of the SETUP message is as follows: <del> The Parameter Value Length field indicates the length of the Parameter Value. </del> <ins> The available versions and SETUP parameters are detailed in the next sections. 6.1.1. MoQ Transport versions are a 32-bit unsigned integer, encoded as a varint.  This version of the specification is identified by the number 0x00000001.  Versions with the most significant 16 bits of the version number cleared are reserved for use in future IETF consensus documents. </ins> The client offers the list of the protocol versions it supports; the server MUST reply with one of the versions offered by the client.  If
client, or the client receives a server version that it did not offer, the corresponding peer MUST close the connection. <del> The SETUP parameters are described in the setup-parameters section. </del> <ins> [[RFC editor: please remove the remainder of this section before publication.]] </ins> <del> 6.1.1. </del> <ins> The version number for the final version of this specification (0x00000001), is reserved for the version of the protocol that is published as an RFC.  Version numbers used to identify IETF drafts are created by adding the draft number to 0xff000000.  For example, draft-ietf-moq-transport-13 would be identified as 0xff00000D. 6.1.2. </ins> Every parameter MUST appear at most once within the SETUP message. The peers SHOULD verify that and close the connection if a parameter
6.6. <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. The format of "UNSUBSCRIBE" is as follows: Full Track Name: Identifies the track as defined in (track-name). 6.7. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.6.1. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. 6.6.1.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. 6.7. </del> <ins> 6.8. </ins> The receiver sends an "ANNOUNCE OK" control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.9. </del> <ins> 6.10. The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.11. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.12. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.12.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.
8. <del> TODO: fill out currently missing registries: * MOQT version numbers * SETUP parameters * Track Request parameters * Subscribe Error codes * Announce Error codes * Track format numbers * Message types * Object headers </del> <ins> TODO: fill out currently missing registries: MOQT version numbers SETUP parameters Track Request parameters Subscribe Error codes Announce Error codes Track format numbers Message types Object headers </ins> TODO: register the URI scheme and the ALPN
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.6.1. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. 6.6.1.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </del> 6.7. The receiver sends an "ANNOUNCE OK" control message to acknowledge
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.10. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.10.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.10.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.10.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.
6.6. <del> A subscriber issues a "UNSUBSCRIBE REQUEST" message to a publisher indicating it is no longer interested in receiving media for the specified track. </del> <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. </ins> <del> The format of "UNSUBSCRIBE REQUEST" is as follows: </del> <ins> The format of "UNSUBSCRIBE" is as follows: </ins> Full Track Name: Identifies the track as defined in (track-name). <del> Track Request Parameters: As defined in track-req-params. </del> 6.7. <del> A "UNSUBSCRIBE OK" control message is sent in response to a successful "UNSUBSCRIBE REQUEST" message. Full Track Name: Identifies the track for which this response is provided. On successfully validating the "UNSUBSCRIBE REQUEST" message, the publisher SHOULD cease delivering objects for the track to the subscriber. 6.8. A publisher sends a "UNSUBSCRIBE ERROR" control message in response to a failed "UNSUBSCRIBE REQUEST" message Full Track Name: Identifies the track in the request message for which this response is provided. Error Code: Identifies an integer error code for the failure. Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for unsubscription error and "Reason Phrase Length" field carries its length. 6.9. </del> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.9.1. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. 6.9.1.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.9.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.9.1.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST, UNSUBSCRIBE and ANNOUNCE messages. 6.10. </del> <ins> 6.8. </ins> The receiver sends an "ANNOUNCE OK" control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.12. </del> <ins> 6.10. The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.11. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without
6.9. <ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.10. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without severing the QUIC connection.  The server can be a producer or a
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.11. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.11.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.
A OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, <del> cache, and forward it. </del> <ins> 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 ix 0x02, the field is not present. </ins> The format of the OBJECT message is as follows:
send-order or priority ordering-by-priorities value. Object Payload Length: The length of the following Object Payload. <del> The sender MAY encode a zero in this field, which means that the message continues to the end of the stream. </del> <ins> If this field is absent, the object payload continues to the end of the stream. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.
The subscriber making the subscribe request is notified of the result of the subscription, via "SUBSCRIBE OK" (message-subscribe-ok) or the <del> "SUBSCRIBE ERROR" message-subscribe-error control message. </del> <ins> "SUBSCRIBE ERROR" message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either an OK or ERROR. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each full track name.  Each new OBJECT belonging to
specific (typically based on prior business agreement). Relays respond with "ANNOUNCE OK" and/or "ANNOUNCE ERROR" control <del> messages providing the results of announcement. </del> <ins> messages providing the results of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of either an OK or ERROR. </ins> OBJECT message header carry short hop-by-hop Track Id that maps to the Full Track Name (see message-subscribe-ok).  Relays use the Track
A "SUBSCRIBE OK" control message is sent for successful subscriptions. <del> Full Track Name: Identifies the track for which this response is provided. </del> <ins> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </ins> Track ID: Session specific identifier that is used as an alias for the Full Track Name in the Track ID field of the OBJECT (message-