Add expectations for SUBSCRIBE_ANNOUNCES, ANNOUNCE, and SUBSCRIBE/FETCH

Author: martinduke

draft-ietf-moq-transport.md

@@ -866,8 +866,9 @@ cache need to protect against cache poisoning.
 A relay MUST NOT reorder or drop objects received on a multi-object stream when
 forwarding to subscribers, unless it has application specific information.
 
-Relays MAY aggregate authorized subscriptions for a given track when
-multiple subscribers request the same track. Subscription aggregation
+Relays SHOULD aggregate authorized subscriptions for a given track when
+multiple subscribers request the same track, using SUBSCRIBE_UPDATE when new
+subscriptions change the aggregate properties. Subscription aggregation
 allows relays to make only a single upstream subscription for the
 track. The published content received from the upstream subscription
 request is cached and shared among the pending subscribers.
@@ -888,21 +889,19 @@ to the old relay can be stopped with an UNSUBSCRIBE.
 
 Publishing through the relay starts with publisher sending ANNOUNCE
 control message with a `Track Namespace` ({{model-track}}).
-The announce enables the relay to know which publisher to forward a
+The ANNOUNCE enables the relay to know which publisher to forward a
 SUBSCRIBE to.
 
-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 the
-  announced namespace. Where the authorization and identification of
-  the publisher occurs depends on the way the relay is managed and
-  is application specific.
+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 the announced namespace. Where the
+authorization and identification of the publisher occurs depends on the way the
+relay is managed and is application specific.
 
 A Relay can receive announcements from multiple publishers for the same
 Track Namespace and it SHOULD respond with the same response to each of the
 publishers, as though it was responding to an ANNOUNCE
-from a single publisher for a given tracknamespace.
+from a single publisher for a given track namespace.
 
 When a publisher wants to stop
 new subscriptions for an announced namespace it sends an UNANNOUNCE.
@@ -911,18 +910,15 @@ namespace it previously responded ANNOUNCE_OK to by sending an
 ANNOUNCE_CANCEL.
 
 A relay manages sessions from multiple publishers and subscribers,
-connecting them based on the track namespace. This MUST use an exact
-match on track namespace unless otherwise negotiated by the application.
-For example, a SUBSCRIBE namespace=foobar message will be forwarded to
-the session that sent ANNOUNCE namespace=foobar.
+connecting them based on the track namespace.
 
 When a relay receives an incoming SUBSCRIBE request that triggers an
 upstream subscription, it SHOULD send a SUBSCRIBE request to each
 publisher that has announced the subscription's namespace, unless it
 already has an active subscription for the Objects requested by the
 incoming SUBSCRIBE request from all available publishers.
 
-When a relay receives an incoming ANNOUCE for a given namespace, for
+When a relay receives an incoming ANNOUNCE for a given namespace, for
 each active upstream subscription that matches that namespace, it SHOULD send a
 SUBSCRIBE to the publisher that sent the ANNOUNCE.
 
@@ -1433,8 +1429,8 @@ See {{priorities}}.
 ## UNSUBSCRIBE {#message-unsubscribe}
 
 A subscriber issues a `UNSUBSCRIBE` message to a publisher indicating it is no
-longer interested in receiving media for the specified track and requests that
-objects stop being sent as soon as possible.
+longer interested in receiving media for the specified track and Objects
+should stop being sent as soon as possible.
 
 The format of `UNSUBSCRIBE` is as follows: