jiebi/CodeConvo huggingface dataset:
Code change:
Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.

Related discussion:
text: 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.
Code change:
Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.

Related discussion:
text: 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
Code change:
This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.

Related discussion:
text: 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.
Code change:
This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.

Related discussion:
text: 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.
Code change:
This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.

Related discussion:
text: EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended. <del> EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested. </del> Subscriber Priority: Specifies the priority of a subscription relative to other subscriptions in the same session.  Lower numbers get higher priority.  See priorities.
Code change:
We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.

Related discussion:
text: is sent right after the last object in the track.  This SHOULD be cached. <del> 0x5 := Indicates end of Subgroup.  Object ID is one greater than the largest normal object ID in the Subgroup. </del> Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation (session-termination).  Any object with a status code other than zero MUST have an empty payload.
Code change:
We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.

Related discussion:
text: 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
Code change:
The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.

Related discussion:
text: 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
Code change:
The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.

Related discussion:
text: the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter. <del> 6.2.2.3. </del> <ins> 6.2.2.2. </ins> The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The
Code change:
As I was reading through the draft, I found some slight typos in the publisher interactions segment. This fixes them!

Related discussion:
text: 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
Code change:
As of now, we use Subscribe ID for operations on a subscriber, and Track Alias for operations on objects. In , there was an effort to remove referencing subscribe id within object header types, but one slipped through. This fixes that.

Related discussion:
text: 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"
Code change:
This is an attempt at clarifying MAXSUBSCRIBEID, feel free to make suggestions.
lgtm
In 6.16 of draft 6, the draft says that "receipt of a MAXSUBSCRIBEID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'." ; however, later the section mentions that "If a 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'." This is can be ambiguous because technically MAXSUBSCRIBEID is any message. Should all sessions be closed if MAXSUBSCRIBEID message contains an invalid Subscribe ID value? Does any message exclude MAXSUBSCRIBEID if an invalid Subscribe ID value is provided? Clarification on this would be helpful. Thank you!
lgtmAgree with Alan's comment. Otherwise LGTM

Related discussion:
text: 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.
Code change:
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM

Related discussion:
text: .  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
Code change:
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM

Related discussion:
text: 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
Code change:
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM

Related discussion:
text: If two objects belong to the same group of the same track received through the same subscription, the one with <del> (for tracks with delivery preference Peep), or </del> <ins> (for tracks with delivery preference Subgroup), or </ins> (for tracks with delivery preference Datagram) is sent first.
Code change:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Related discussion:
text: 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
Code change:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Related discussion:
text: 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.
Code change:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Related discussion:
text: 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
Code change:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Related discussion:
text: 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.