jiebi/CodeConvo huggingface dataset:
Code change:
Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?

Related discussion:
text: Track Namespace: Identifies a track's namespace as defined in (track-name). <ins> Error Code: Identifies an integer error code for canceling the announcement. Reason Phrase: Provides the reason for announcement cancelation. </ins> 6.10. A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the
Code change:
Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?

Related discussion:
text: SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or <del> authorized to access a subset of available annoucements. </del> <ins> authorized to access a subset of available announcements. </ins> 6.12.
Code change:
Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?

Related discussion:
text: Announce Error codes <ins> Announce Cancel Reason codes </ins> Message types TODO: register the URI scheme and the ALPN
Code change:
Sorry for the late response but I dont think this text is quite correct. If you're running MoQ over WebTransport, you're likely to be following the instructions in URL, which states My reading of the current text means that endpoints are likely to blend up treating things as a violation when there is no violation.
Section 3.3 says: "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'." I know we have multiple transports, but it would be good to clarify what an abrupt close is. Presumably any sort of RESET_STREAM, but what happens if there's a FIN? Is this a "clean close" of the session? Does it imply or force a reset of data streams?
LGTM

Related discussion:
text: 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.
Code change:
My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM

Related discussion:
text: 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.
Code change:
My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM

Related discussion:
text: 3.5. <del> The transport session can be terminated at any point.  When native </del> <ins> The Transport Session can be terminated at any point.  When native </ins> QUIC is used, the session is closed using the CONNECTION_CLOSE frame (QUIC).  When WebTransport is used, the session is closed using the CLOSE_WEBTRANSPORT_SESSION capsule (WebTransport).
Code change:
My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM

Related discussion:
text: (CDNs).  Additionally, relays serve as policy enforcement points by validating subscribe and publish requests at the edge of a network. <ins> Relays are endpoints, which means they terminate Transport Sessions in order to have visibility of MoQ Object metadata. </ins> Relays can cache Objects, but are not required to. 5.1.
Code change:
This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.

Related discussion:
text: 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.
Code change:
This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.

Related discussion:
text: 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.
Code change:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Related discussion:
text: 6.1.1.1. AUTHORIZATION INFO parameter (key 0x02) identifies a track's <del> authorization information in a SUBSCRIBE, SUBSCRIBE_NAMESPACE or </del> <ins> authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or </ins> ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string.
Code change:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Related discussion:
text: 6.11. <del> The subscriber sends the SUBSCRIBE_NAMESPACE control message to a </del> <ins> The subscriber sends the SUBSCRIBE_ANNOUNCES control message to a </ins> publisher to request the current set of matching announcements, as well as future updates to the set.
Code change:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Related discussion:
text: 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
Code change:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Related discussion:
text: 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.
Code change:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

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