jiebi/CodeConvo huggingface dataset:
object does not exist at any publisher and it will not be published in the future.  This SHOULD be cached. <del> 0x2 := Indicates Group does not exist.  Indicates that objects with this GroupID do not exist at any publisher and they will not be published in the future.  This SHOULD be cached. </del> 0x3 := Indicates end of Group.  ObjectId is one greater that the largest object produced in the group identified by the GroupID. <del> This is sent right after the last object in the group.  This SHOULD be cached. </del> <ins> This is sent right after the last object in the group.  If the ObjectID is 0, it indicates there are no Objects in this Group. This SHOULD be cached. </ins> 0x4 := Indicates end of Track and Group.  GroupID is one greater than the largest group produced in this track and the ObjectId is
more than one Peep and the priority varies between these Peeps, higher priority Peeps are sent before lower priority Peeps.  If the specified priority of two Peeps in a Group are equal, the lower Peep <del> ID has priority.  Within a Peep, Objects MUST bs sent in increasing </del> <ins> ID has priority.  Within a Peep, Objects MUST be sent in increasing </ins> Object ID order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until the publisher of the track terminates the track with a <del> SUBSCRIBE_DONE (see message-subscribe-done). </del> <ins> SUBSCRIBE_DONE (see message-subscribe-done).  A caching relay saves objects to its cache identified by the object's fulltrackname, group ID and object ID.  Relays MUST be ready to process objects for the same fulltrackname from multiple publishers and the objects received are forwarded to active matching subscribers.  If multiple objects are received with the same fulltrackname, group ID and object ID - a caching Relays MUST drop the received objects as duplicate if there exists already an object with the matching fulltrackame, group ID and object ID, in its cache. </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it
The application SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below: <ins> 5.1.1. This section describes behavior a subscriber MAY implement to allow for a better user experience when a relay sends a GOAWAY. When a subscriber receives the GOAWAY message, it starts of the process of connecting to a new relay and sending the SUBSCRIBE requests for all it's active subscriptions to the new relay.  The new relay will send a response to the subscribes and once this has happened, the subscription to the old relay can be stopped with an UNSUBSCRIBE. </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE <del> control message with a "Track Namespace" (model-track). </del> <ins> control message with a "Track Namespace" (model-track).  The annouce allows the relays to know which publisher to forward a SUBSCRIBE to. </ins> Relays MUST ensure that publishers are authorized by: Verifying that the publisher is authorized to publish the content associated with the set of tracks whose Track Namespace matches <del> the announced namespace.  Specifics of where the authorization happens, either at the relays or forwarded for further processing, depends on the way the relay is managed and is application specific (typically based on prior business agreement). </del> <ins> the announced namespace.  Specifics of where the authorization and identification of the publisher happens either at the relays or forwarded for further processing, depends on the way the relay is managed and is application specific (typically based on prior business agreement). </ins> 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.  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. </del> <ins> either ANNOUNCE_OK or ANNOUNCE_ERROR. A Relay can receive announcements from multiple publishers for the same tracknamespace and it MUST respond with appropriate response to each of the publishers, in the same way as it would responds when processing ANNOUNCE from a single publisher for a given tracknamespace. 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> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact
application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. <ins> When a relay receives an incoming SUBSCRIBE for a given namespace, for each publisher that has announced that namespace, the relay MUST send a SUBSCRIBE to that publisher unless it already has an active subscription to that publisher for the full track name in the incoming SUBSCRIBE. When a relay receives an incoming ANNOUCE for a given namespace, for each active subscription that matches that namespace, it MUST send a SUBSCRIBE to that publisher that send the ANNOUCE. </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
OBJECT messages to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout. <ins> 5.2.1. This section describes non normative behavior that a publisher MAY choose to implement to allow for a better users experience when switching from WiFi to Cellular networks or visa versa. If the original publisher detects it is likely to need to switch networks, for example because the WiFi signal is getting weaker, and it does not have QUIC connection migration available, it establishes a new session over the new interface and sends an ANNOUCE.  The relay will forward matching subscribes and the publisher publishes objects on both sessions.  Once the subscriptions have migrated over to session on the new network, the publisher can stop publishing objects on the old network.  The relay will drop duplicate objects received on both subscriptions.  Ideally, the subscriptions downstream from the relay do no observe this change, and keep receiving the objects on the same subscription. 5.2.2. This section describes non normative behavior that a publisher MAY choose to implement to allow for a better users experience when a relay sends them a GOAWAY. When a publisher receives a GOAWAY, it starts the process of connecting to a new relay and sends announces, but it does not immediately stop publishing objects to the old relay.  The new relay will send subscribes and the publisher can start sending new objects to the new relay instead of the old relay.  Once objects are going to the new relay, the announcement and subscription to the old relay can be stopped. </ins> 5.3. MOQT encodes the delivery information for a stream via OBJECT headers
session as a 'Protocol Violation' if it receives a second bidirectional stream. <del> 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'. </del> <ins> The control stream MUST NOT be closed at the underlying transport layer while the session is active.  Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.4.
time. Objects are comprised of two parts: metadata and a payload.  The <del> 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 Original Publisher and End Subscribers.  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> metadata is never encrypted and is always visible to relays (see relays-moq).  The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers.  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.
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 <del> fields will not be present. </del> <ins> fields will not be present.  Any other value is a protocol error and MUST terminate the session with a Protocol Violation (session- termination). </ins> Largest Group ID: The largest Group ID available for this track. This field is only present if ContentExists has a value of 1.
ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final <del> Object fields will not be present. </del> <ins> Object fields will not be present.  Any other value is a protocol error and MUST terminate the session with a Protocol Violation (session-termination). </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.
example, if the publisher is a relay that has received ANNOUNCE messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", <del> "participant=200"), a SUBSCRIBE_NAMESPACE for ("example.com", </del> <ins> "participant=200"), a SUBSCRIBE_ANNOUNCES for ("example.com", </ins> "meeting=123") would match both. Parameters: The parameters are defined in version-specific-params. <del> The publisher will respond with SUBSCRIBE_NAMESPACE_OK or SUBSCRIBE_NAMESPACE_ERROR.  If the SUBSCRIBE_NAMESPACE is successful, </del> <ins> The publisher will respond with SUBSCRIBE_ANNOUNCES_OK or SUBSCRIBE_ANNOUNCES_ERROR.  If the SUBSCRIBE_ANNOUNCES is successful, </ins> the publisher will forward any matching ANNOUNCE messages to the subscriber that it has not yet sent.  If the set of matching ANNOUNCE messages changes, the publisher sends the corresponding ANNOUNCE or
A subscriber cannot make overlapping namespace subscriptions on a single session.  Within a session, if a publisher receives a <del> SUBSCRIBE_NAMESPACE with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_NAMESPACE or vice versa, it MUST respond with SUBSCRIBE_NAMESPACE_ERROR, with error code SUBSCRIBE_NAMESPACE_OVERLAP. </del> <ins> SUBSCRIBE_ANNOUNCES with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_ANNOUNCES or vice versa, it MUST respond with SUBSCRIBE_ANNOUNCES_ERROR, with error code SUBSCRIBE_ANNOUNCES_OVERLAP. </ins> The publisher MUST ensure the subscriber is authorized to perform this namespace subscription. <del> SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE </del> <ins> SUBSCRIBE_ANNOUNCES is not required for a publisher to send ANNOUNCE </ins> and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or authorized to access a subset of available announcements. 6.12. <del> A subscriber issues a "UNSUBSCRIBE_NAMESPACE" message to a publisher </del> <ins> A subscriber issues a "UNSUBSCRIBE_ANNOUNCES" message to a publisher </ins> indicating it is no longer interested in ANNOUNCE and UNANNOUNCE messages for the specified track namespace prefix. <del> The format of "UNSUBSCRIBE_NAMESPACE" is as follows: </del> <ins> The format of "UNSUBSCRIBE_ANNOUNCES" is as follows: </ins> Track Namespace Prefix: As defined in message-subscribe-ns.
6.20. <del> A publisher sends a SUBSCRIBE_NAMESPACE_OK control message for </del> <ins> A publisher sends a SUBSCRIBE_ANNOUNCES_OK control message for </ins> successful namespace subscriptions. Track Namespace Prefix: As defined in message-subscribe-ns. 6.21. <del> A publisher sends a SUBSCRIBE_NAMESPACE_ERROR control message in response to a failed SUBSCRIBE_NAMESPACE. </del> <ins> A publisher sends a SUBSCRIBE_ANNOUNCES_ERROR control message in response to a failed SUBSCRIBE_ANNOUNCES. </ins> Track Namespace Prefix: As defined in message-subscribe-ns.
A subscription causes the publisher to send newly published objects for a track.  A subscriber MUST NOT make multiple active subscriptions for a track within a single session and publishers <del> SHOULD treat this as a protocol violation. </del> <ins> SHOULD treat this as a protocol violation.  The only objects prior to the current object that can be requested are those in the current group. </ins> The subscriber specifies a filter on the subscription to allow the publisher to identify which objects need to be delivered.
AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields. <ins> If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and <del> StartObject. </del> <ins> StartObject.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> A filter type other than the above MUST be treated as error. <ins> If a subscriber wants to subscribe to Objects both before and after the Latest Object, it can send a SUBSCRIBE for the Latest Object followed by a FETCH.  Depending upon the application, one might want to send both messages at the same time or wait for the first to return before sending the second. </ins> The format of SUBSCRIBE is as follows: Subscribe ID: The subscriber specified identifier used to manage a
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </del> <ins> start and end of the range are inclusive.  EndGroup MUST specify the same or a later group than StartGroup.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> A filter type other than the above MUST be treated as error.
StartObject: The start Object ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. <del> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested.  Only present for the "AbsoluteRange" filter type. </del> <ins> EndGroup: The end Group ID, inclusive.  Only present for the "AbsoluteRange" filter type. </ins> Subscribe Parameters: The parameters are defined in version- specific-params.
received all objects in a subgroup from the start of the subscription.  If a relay, it can forward stream FINs to its own subscribers once those objects have been sent.  A relay MAY treat <del> receipt of EndOfGroup, EndOfSubgroup, GroupDoesNotExist, or EndOfTrack objects as a signal to close corresponding streams even if the FIN has not arrived, as further objects on the stream would be a protocol violation. </del> <ins> receipt of EndOfGroup, GroupDoesNotExist, or EndOfTrack objects as a signal to close corresponding streams even if the FIN has not arrived, as further objects on the stream would be a protocol violation. </ins> Similarly, an EndOfGroup message indicates the maximum Object ID in the Group, so if all Objects in the Group have been received, a FIN
6.2.2.1. <del> The ROLE parameter (key 0x00) allows each endpoint to independently specify what functionality they support for the session.  It has three possible values, which are of type varint: 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. 6.2.2.2. </del> The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a
When a relay receives an incoming ANNOUCE for a given namespace, for each active upstream subscription that matches that namespace, it <del> SHOULD send a SUBSCRIBE to that publisher that send the ANNOUNCE. </del> <ins> SHOULD send a SUBSCRIBE to the publisher that sent the ANNOUNCE. </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
When a stream begins with "STREAM_HEADER_SUBGROUP", all objects on the stream belong to the track requested in the Subscribe message <del> identified by "Subscribe ID" and the subgroup indicated by 'Group ID' </del> <ins> identified by "Track Alias" and the subgroup indicated by 'Group ID' </ins> and "Subgroup ID". All Objects received on a stream opened with "STREAM_HEADER_SUBGROUP"
Subscribe ID value is a 'Protocol Violation'. Subscribe ID: The new Maximum Subscribe ID for the session.  If a <del> Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'.  More on Subscribe ID in message- subscribe-req. </del> <ins> Subscribe ID message-subscribe-req equal or larger than this is received by the publisher that sent the MAX_SUBSCRIBE_ID, the publisher MUST close the session with an error of 'Too Many Subscribes'. </ins> 6.21.
.  A schedulable object in MoQT is either: <del> An object that belongs to a peep where that object would be the next object to be sent in that peep. </del> <ins> An object that belongs to a subgroup where that object would be the next object to be sent in that subgroup. </ins> An object that belongs to a track with delivery preference Datagram. <del> Since a single peep or datagram has a single publisher priority, it can be useful to conceptualize this process as scheduling peeps or datagrams instead of individual objects on them. </del> <ins> Since a single subgroup or datagram has a single publisher priority, it can be useful to conceptualize this process as scheduling subgroups or datagrams instead of individual objects on them. </ins> A
what happens to objects that have already been received and possibly scheduled. <del> is a priority number associated with an indiviaul schedulable object. It is specified in the header of the respective peep or datagram, and is the same for all objects in a single peep. </del> <ins> is a priority number associated with an individual schedulable object.  It is specified in the header of the respective subgroup or datagram, and is the same for all objects in a single subgroup. </ins> is a property of an invidual subscription.  It can be either 'Ascending' (groups with lower group ID are sent first), or
6.1.1.1. <del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the </del> <ins> AUTHORIZATION INFO parameter (Parameter Type 0x02) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the </ins> authorization is required at the track level.  The value is an ASCII string. 6.1.1.2. <del> The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference.  There is no explicit signal that an Object was not sent because the delivery timeout was exceeded. </del> <ins> The DELIVERY TIMEOUT parameter (Parameter Type 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference.  There is no explicit signal that an Object was not sent because the delivery timeout was exceeded. </ins> If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD
6.1.1.3. <del> MAX_CACHE_DURATION (key 0x04): An integer expressing a number of milliseconds.  If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received.  This means Objects earlier in a multi- object stream will expire earlier than Objects later in the stream. Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re-requests them. </del> <ins> MAX_CACHE_DURATION (Parameter Type 0x04): An integer expressing a number of milliseconds.  If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received.  This means Objects earlier in a multi-object stream will expire earlier than Objects later in the stream.  Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re- requests them. </ins> 6.2.
6.2.2.1. <del> The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a PATH parameter from the server, or when WebTransport is used, it MUST close the connection.  It follows the URI formatting rules RFC3986. </del> <ins> The PATH parameter (Parameter Type 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a PATH parameter from the server, or when WebTransport is used, it MUST close the connection.  It follows the URI formatting rules RFC3986. </ins> When connecting to a server using a URI with the "moqt" scheme, the client MUST set the PATH parameter to the "path-abempty" portion of
6.2.2.2. <del> The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </del> <ins> The MAX_SUBSCRIBE_ID parameter (Parameter Type 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </ins> 6.3.