jiebi/CodeConvo huggingface dataset:
3.3. <del> A QUIC stream MAY be canceled at any point with an error code.  The producer does this via a "RESET_STREAM" frame while the consumer requests cancellation with a "STOP_SENDING" frame. When using "order", lower priority streams will be starved during congestion, perhaps indefinitely.  These streams will consume resources and flow control until they are canceled.  When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion.  This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation.  Is this section required, or can it be deleted, or added to a new "workflow" section. </del> <ins> QUIC streams aside from the control stream MAY be canceled due to congestion or other reasons by either the sender or receiver.  Early termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.
3.2. <del> The first stream opened is a client-initiated bidirectional stream where the peers exchange SETUP messages (message-setup).  The subsequent streams MAY be either unidirectional or bidirectional. For exchanging content, an application would typically send a unidirectional stream containing a single OBJECT message (message- object), as putting more than one object into one stream may create head-of-line blocking delays.  However, if one object has a hard dependency on another object, putting them on the same stream could be a valid choice. </del> <ins> The first stream opened is a client-initiated bidirectional control stream where the peers exchange SETUP messages (message-setup).  All messages defined in this draft are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no other uses of bidirectional streams, a peer MAY currently close the connection if it receives a second bidirectional stream. The control stream MUST NOT be abruptly closed at the QUIC layer. Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.3.
subscribers for each full track name.  Each new OBJECT belonging to the track is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, <del> until the publisher of the track stops producing objects or there is a subscription error (see message-subscribe-error). </del> <ins> until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
6.7. <ins> A publisher issues a "SUBSCRIBE_FIN" message to all subscribers indicating it is done publishing objects on the subscribed track. The format of "SUBSCRIBE_FIN" is as follows: Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track. Final Object: The largest Object Sequence sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.8. A publisher issues a "SUBSCRIBE_RST" message to all subscribers indicating there wan an error publishing to the given track and subscription is terminated. The format of "SUBSCRIBE_RST" is as follows: Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). Error Code: Identifies an integer error code for subscription failure. Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track. Final Object: The largest Object Sequence sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.9. </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
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. </del> <ins> established.  There is no definition of the protocol over other transports, such as TCP, and applicaitons using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </ins> 3.1.1.
Abstract This document defines the core behavior for Media over QUIC Transport <del> (MOQT), a media transport protocol over QUIC.  MOQT 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. </del> <ins> (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality.  MOQT 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> Media Over QUIC Transport (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 </del> <ins> Media Over QUIC Transport (MOQT) is a protocol that is optimized for the QUIC 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 </ins> resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks.
other uses of bidirectional streams, a peer MAY currently close the connection if it receives a second bidirectional stream. <del> The control stream MUST NOT be abruptly closed at the QUIC layer. Doing so results in the session being closed as a 'Protocol Violation'. </del> <ins> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.3. <del> QUIC streams aside from the control stream MAY be canceled due to </del> <ins> Streams aside from the control stream MAY be canceled due to </ins> congestion or other reasons by either the sender or receiver.  Early <del> termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </del> <ins> termination of a stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.
object are still delivered in order; this send order only applies to the ordering between objects. <del> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (priority-congestion) such that streams are transmitted in send order. </del> <ins> A sender MUST send each object over a dedicated stream.  The library should support prioritization (priority-congestion) such that streams are transmitted in send order. </ins> A receiver MUST NOT assume that objects will be received in send order, for the following reasons:
A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data <del> to be buffered in the QUIC library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write QUIC stream data out of order subject to flow control limits.  See section 2.2 in QUIC. </del> <ins> to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write stream data out of order subject to flow control limits.  See section 2.2 in QUIC. </ins> 6. <del> Both unidirectional and bidirectional QUIC streams contain sequences of length-delimited messages. </del> <ins> Both unidirectional and bidirectional streams contain sequences of length-delimited messages. </ins> An endpoint that receives an unknown message type MUST close the connection.
Live content requires significant bandwidth and resources.  Failure to set limits will quickly cause resource exhaustion. <del> MOQT uses QUIC flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </del> <ins> MOQT uses stream limits and flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </ins> Endpoints MAY impose a MAX STREAM count limit which would restrict the number of concurrent streams which a MOQT Streaming Format could
given URI by setting up a QUIC connection to the host and port identified by the "authority" section of the URI.  The "path-abempty" and "query" portions of the URI are communicated to the server using <del> the PATH parameter (path) which is sent in the SETUP message at the start of the session.  The ALPN value RFC7301 used by the protocol is "moq-00". </del> <ins> the PATH parameter (path) which is sent in the CLIENT_SETUP message at the start of the session.  The ALPN value RFC7301 used by the protocol is "moq-00". </ins> 3.2. Endpoints use the exchange of SETUP messages to negotiate the MOQT version and any extensions to use. <del> The client indicates the MOQT versions it supports in its SETUP message (see message-setup).  It also includes the union of all Setup Parameters setup-params required for a handshake by any of those versions. </del> <ins> The client indicates the MOQT versions it supports in the CLIENT_SETUP message (see message-setup).  It also includes the union of all Setup Parameters setup-params required for a handshake by any of those versions. </ins> Within any MOQT version, clients request the use of extensions by adding SETUP parameters corresponding to that extension.  No extensions are defined in this document. <del> The server replies with a SETUP message that indicates the chosen version, includes all parameters required for a handshake in that version, and parameters for every extension requested by the client that it supports. </del> <ins> The server replies with a SERVER_SETUP message that indicates the chosen version, includes all parameters required for a handshake in that version, and parameters for every extension requested by the client that it supports. </ins> New versions of MOQT MUST specify which existing extensions can be used with that version.  New extensions MUST specify the existing
6.2. <del> The "SETUP" message is the first message that is exchanged by the 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 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. </del> <ins> The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages exchanged by the client and the server; they 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 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> <del> The wire format of the SETUP message is as follows: </del> <ins> The wire format of the SETUP messages is as follows: </ins> The available versions and SETUP parameters are detailed in the next sections.
6.1.1.1. <del> The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects in a SUBSCRIBE message.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  The value is of type varint. 6.1.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects in a SUBSCRIBE message.  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. The value is of type varint. 6.1.1.3. </del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE or ANNOUNCE message.  This parameter is populated for cases where the authorization is required
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <del> OBJECT message header carry short hop-by-hop Track Id that maps to </del> <ins> OBJECT message header carry short hop-by-hop Track ID that maps to </ins> the Full Track Name (see message-subscribe-ok).  Relays use the Track ID of an incoming OBJECT message to identify its track and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT
specified track, as well as associated metadata required to deliver, cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is <del> present.  When the message type ix 0x02, the field is not present. </del> <ins> present.  When the message type is 0x02, the field is not present. </ins> The format of the OBJECT message is as follows: <del> Track ID: The track identifier obtained as part of subscription and/or publish control message exchanges. </del> <ins> Track ID : The compressed full track name obtained as part of subscription and/or publish control message exchanges. </ins> Group Sequence : The object is a member of the indicated group model-group within the track.
6.4.2. <del> The format of SUBSCRIBE REQUEST is as follows: </del> <ins> The format of SUBSCRIBE is as follows: </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> Subscribe ID: Session unique identifier for the subscription. "Subscribe ID" is monotonically increasing variable length integer and it MUST uniquely identify a subscription within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR. </ins> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None.
the Full Track Name in the Track ID field of the OBJECT (message- object) message headers of the requested track.  Track IDs are generally shorter than Full Track Names and thus reduce the <del> overhead in OBJECT messages. </del> <ins> overhead in OBJECT messages Subscribe ID: Subscription Identifer from the incoming subscription request for which this message is the response. </ins> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays
This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no other uses of bidirectional streams, a peer MAY currently close the <del> connection if it receives a second bidirectional stream. </del> <ins> session as a 'Protocol Violation' if it receives a second bidirectional stream. </ins> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a
5.3. <del> TODO: This section shall cover aspects of relay failover and protocol interactions. 5.4. TODO: This section shall cover reconnect considerations for clients when moving between the Relays. 5.5. </del> TODO: Refer to priority-congestion.  Add details to describe relay behavior when merging or splitting streams and interactions with congestion response. <del> 5.6. </del> <ins> 5.4. </ins> MOQT encodes the delivery information for a stream via OBJECT headers (message-object).
The first stream opened is a client-initiated bidirectional control stream where the peers exchange SETUP messages (message-setup).  All <del> messages defined in this draft are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del> <ins> messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no
in time, two tracks within the same scope contain different data, they have to have different full track names. <ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of bytes and comparison between two Track Namespaces or Track Names is done by exact comparison of the bytes.  Specifications that use MoQ Transport may constrain the information in these fields, for example by restricting them to UTF-8.  Any specification that does needs to specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. </ins> 2.3.2. Each track MAY have one or more associated connection URLs specifying
associated with it.  A track name identifies an individual track within the namespace. <del> A tuple of a track name and a track namespace together is known as a full track name: </del> A MOQT scope is a set of servers (as identified by their connection <del> URIs) for which full track names are guaranteed to be unique.  This implies that within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.  It is up to the application using MOQT to define how broad or narrow the scope has to be.  An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs. The full track name is the only piece of information that is used to identify the track within a given MOQT scope and is used as cache key.  MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP (RFC9110); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different full track names. </del> <ins> URIs) for which the tuple of Track Name and Track Namespace are guaranteed to be unique and identify a specific track.  It is up to the application using MOQT to define how broad or narrow the scope is.  An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs. Because the tuple of Track Namespace and Track Name are unique within an MOQT scope, they can be used as a cache key.  MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP (RFC9110); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different names and/or namespaces. </ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of
Subscribers interact with the Relays by sending a SUBSCRIBE (message- subscribe-req) control message for the tracks of interest.  Relays MUST ensure subscribers are authorized to access the content <del> associated with the Full Track Name.  The authorization information can be part of subscription request itself or part of the encompassing session.  The specifics of how a relay authorizes a user are outside the scope of this specification. </del> <ins> associated with the track.  The authorization information can be part of subscription request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification. </ins> The subscriber making the subscribe request is notified of the result of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the
SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. For successful subscriptions, the publisher maintains a list of <del> subscribers for each full track name.  Each new OBJECT belonging to the track 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 track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> 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 until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). <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. </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription aggregation allows relays to make only a single forward subscription