Announce #643

martinduke · 2024-12-13T19:38:37Z

Fixes #556
Fixes #557
Fixes #577
Fixes #583
Fixes #584

Also eliminates text from the relay section that is redundant, because it applies to endpoints whether or not they are relays.

ianswett

I still find some of the ANNOUNCE flow overly complex, but this does a good job of describing how you might use the defined messages.

ianswett · 2024-12-17T21:03:00Z

draft-ietf-moq-transport.md

+
+If the subscriber is aware of a namespace of interest, it can send
+SUBSCRIBE_ANNOUNCES to publishers/relays it has discovered. This message
+increases the likelihood that publishers will send relevant ANNOUNCE messages


Isn't it required to send ANNOUNCES that match the prefix?

The normative words are in the ANNOUNCE section. I had SHOULD under the general theory of "server's gonna do..." but I'll change it to MUST because I don't think it matters that much. The question is "MUST if what?" and my next edit will attempt to answer that.

draft-ietf-moq-transport.md

afrind

Individual Review:

Thanks for tackling this. There's a lot going on here.

Moving the error codes is helpful but seems like a great candidate for a standalone editorial PR.

There are some normative changes to relay handling not related to ANNOUNCE which should also be in a separate PR.

There's a subtle deletion of the "exact" namespace matching behavior. This is less problematic in the face of structured namespaces, but I forget if that was something we discussed and had consensus on?

afrind · 2024-12-18T01:25:06Z

draft-ietf-moq-transport.md

+increases the likelihood that publishers will send relevant ANNOUNCE messages
+for that namespace.
+
+An UNSUBSCRIBE_NAMESPACES negates the effect of a SUBSCRIBE_NAMESPACES. It does


"negates the effect" has me reaching for a D20

'withdraws a previous SUBSCRIBE_NAMESPACES' ?

draft-ietf-moq-transport.md

martinduke · 2024-12-18T21:11:44Z

Individual Review:

Thanks for tackling this. There's a lot going on here.

Moving the error codes is helpful but seems like a great candidate for a standalone editorial PR.

This PR is already heavily editing the relay section for redundant and poorly located text. This falls into that theme; it is not specific to relays.

There are some normative changes to relay handling not related to ANNOUNCE which should also be in a separate PR.

Again, a huge rewrite of the Relay section is in scope for this.

There's a subtle deletion of the "exact" namespace matching behavior. This is less problematic in the face of structured namespaces, but I forget if that was something we discussed and had consensus on?

I don't see how structured namespaces can work with exact matching.

afrind

This looks better. A bunch of editorial comments/suggestions. The substantive comment is about superset.

afrind · 2025-01-11T00:23:41Z

draft-ietf-moq-transport.md

@@ -612,6 +612,105 @@ and announcements. The client can choose to delay closing the session if it
 expects more OBJECTs to be delivered. The server closes the session with a
 'GOAWAY Timeout' if the client doesn't close the session quickly enough.

+# Track Discovery and Retrieval (#track-discovery}
+
+Discovery of MoQT servers is always done out-of-band. Track discovery is done in


s/is done/can be done/ ?

There are cases where track discovery is also out of band (eg catalog, hard coded in specifications), right?

afrind · 2025-01-11T00:24:12Z

draft-ietf-moq-transport.md

+
+Discovery of MoQT servers is always done out-of-band. Track discovery is done in
+the context of an established MoQT session. The session client might be a
+subscriber, publisher, or both.


The session client might be a subscriber, publisher, or both.

This is true, but is it related to track discovery?

afrind · 2025-01-11T00:24:34Z

draft-ietf-moq-transport.md

+
+Given sufficient out of band information, it is valid for a subscriber
+to send a SUBSCRIBE or FETCH message to a publisher (including a relay) without
+any previous MoQT messages besides SETUP. However, SUBSCRIBE_NAMESPACES and


SUBSCRIBE_ANNOUNCES

afrind · 2025-01-11T00:27:07Z

draft-ietf-moq-transport.md

+Given sufficient out of band information, it is valid for a subscriber
+to send a SUBSCRIBE or FETCH message to a publisher (including a relay) without
+any previous MoQT messages besides SETUP. However, SUBSCRIBE_NAMESPACES and
+ANNOUNCE messages provide an in-band means of discovery of subscribers and


I don't think you can discover subscribers via these messages.

...discovery of publishers and track namespaces?

Aside: I've been thinking there might be value in an optional track name (or names) in ANNOUNCE, to assist with catalog-less discovery.

afrind · 2025-01-11T00:29:23Z

draft-ietf-moq-transport.md

+
+If the subscriber is aware of a namespace of interest, it can send
+SUBSCRIBE_ANNOUNCES to publishers/relays it has discovered. This message
+increases the likelihood that publishers will send relevant ANNOUNCE messages


I don't like 'increases the likelihood'. Maybe:

The recipient of the message will send any relevant ANNOUNCE messages for that namespace.

afrind · 2025-01-11T00:49:00Z

draft-ietf-moq-transport.md

+UNANNOUNCE. A publisher and subscriber might seek alternate subscribers and
+publishers, respectively, for potential SUBSCRIBE and FETCH interactions.
+
+The receiver of an ANNOUNCE_OK or ANNOUNCE_ERROR SHOULD report this to the


Should this section move closer to ANNOUNCE (above UNANNOUNCE/ANNOUNCE_CANCEL)

afrind · 2025-01-11T00:52:41Z

draft-ietf-moq-transport.md

+data stream is already open, it MAY send STOP_SENDING for the data stream along
+with FETCH_CANCEL, but MUST send FETCH_CANCEL.
+
+The Publisher can destroy subscription or fetch state as soon as it has received


The order you have is:

subscriber SUBSCRIBE state
subscriber FETCH state
publisher FETCH state
publisher SUBSCRIBE state

which I find dissatisfying. Can you reorder (either sub sub/sub fetch/pub sub/pub fetch, or sub sub/pub sub/sub fetch/pub fetch is fine)

afrind · 2025-01-11T00:53:09Z

draft-ietf-moq-transport.md

+has received an ANNOUNCE with a namespace that includes that track, it SHOULD
+only request it from the senders of those ANNOUNCE messages.
+
+The central interaction with a publisher is to send SUBSCRIBE and/or FETCH for


Maybe reorder these to paragraphs?

afrind · 2025-01-11T00:55:37Z

draft-ietf-moq-transport.md

@@ -1545,16 +1585,28 @@ message for which this response is provided.

 * Reason Phrase: Provides the reason for announcement error.

+The following error codes are defined:


I'm not going to die on this hill, but moving the error code tables could easily go in another PR.

afrind · 2025-01-11T00:55:45Z

draft-ietf-moq-transport.md

+both endpoints can immediately destroy relevant state. Objects MUST NOT be sent
+for requests that end with an error.
+
+A publisher MUST send exactly one SUBSCRIBE_OK or SUBSCRIBE_ERROR in response to


Move closer to the top of the section, before the state bits.

martinduke added 2 commits December 13, 2024 19:00

Add expectations for SUBSCRIBE_ANNOUNCES, ANNOUNCE, and SUBSCRIBE/FETCH

0ff3d31

Added more issues

be7029d

martinduke requested a review from ianswett December 13, 2024 19:39

lint

71a2a21

ianswett reviewed Dec 17, 2024

View reviewed changes

ianswett added Announce Issues with Announce message and handling Design Issues or PRs that change how MoQ works including the wire format. labels Dec 17, 2024

martinduke added 2 commits December 17, 2024 22:29

Ian comments

39e8cb4

Tune up announce rules

d414bef

afrind reviewed Dec 18, 2024

View reviewed changes

alan comments

185270d

martinduke mentioned this pull request Jan 8, 2025

Add FETCH to Relay section #645

Open

Remove stuff from PR#645

b65ca89

martinduke mentioned this pull request Jan 10, 2025

Editorial changes #646

Open

martinduke added 3 commits January 10, 2025 19:52

Remove #646

ca408ae

Require exact namespace match

81d7c19

MAY aggregate subscriptions

c658e3f

afrind reviewed Jan 11, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Announce #643

Announce #643

martinduke commented Dec 13, 2024

ianswett left a comment

ianswett Dec 17, 2024

martinduke Dec 17, 2024 •

edited

Loading

afrind left a comment

afrind Dec 18, 2024

afrind Jan 11, 2025

martinduke commented Dec 18, 2024

afrind left a comment

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

afrind Jan 11, 2025

		@@ -1545,16 +1585,28 @@ message for which this response is provided.

		* Reason Phrase: Provides the reason for announcement error.

		The following error codes are defined:

Announce #643

Are you sure you want to change the base?

Announce #643

Conversation

martinduke commented Dec 13, 2024

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinduke Dec 17, 2024 • edited Loading

Choose a reason for hiding this comment

afrind left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinduke commented Dec 18, 2024

afrind left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinduke Dec 17, 2024 •

edited

Loading