Code change:
1.1. The development of MOQT is driven by goals in a number of areas - <del> specifically latency, the robustness of QUIC, workflow efficiency and relay support. </del> <ins> specifically latency, the robust feature set of QUIC and relay support. </ins> 1.1.1. <del> HTTP Adaptive Streaming (HAS) has been successful at achieving scale although often at the cost of latency.  Latency is necessary to correct for variable network throughput.  Ideally live content is consumed at the same bitrate it is produced.  End-to-end latency would be fixed and only subject to encoding and transmission delays. Unfortunately, networks have variable throughput, primarily due to congestion.  Attempting to deliver content encoded at a higher bitrate than the network can support causes queuing along the path from producer to consumer.  The speed at which a protocol can detect and respond to queuing determines the overall latency.  TCP-based protocols are simple but are slow to detect congestion and suffer from head-of-line blocking.  Protocols utilizing UDP directly can avoid queuing, but the application is then responsible for the complexity of fragmentation, congestion control, retransmissions, receiver feedback, reassembly, and more.  One goal of MOQT is to achieve the best of both these worlds: leverage the features of QUIC to create a simple yet flexible low latency protocol that can rapidly detect and respond to congestion. </del> <ins> Latency is necessary to correct for variable network throughput. Ideally live content is consumed at the same bitrate it is produced. End-to-end latency would be fixed and only subject to encoding and transmission delays.  Unfortunately, networks have variable throughput, primarily due to congestion.  Attempting to deliver content encoded at a higher bitrate than the network can support causes queuing along the path from producer to consumer.  The speed at which a protocol can detect and respond to congestion determines the overall latency.  TCP-based protocols are simple but are slow to detect congestion and suffer from head-of-line blocking.  Protocols utilizing UDP directly can avoid queuing, but the application is then responsible for the complexity of fragmentation, congestion control, retransmissions, receiver feedback, reassembly, and more.  One goal of MOQT is to achieve the best of both these worlds: leverage the features of QUIC to create a simple yet flexible low latency protocol that can rapidly detect and respond to congestion. </ins> 1.1.2. The parallel nature of QUIC streams can provide improvements in the face of loss.  A goal of MOQT is to design a streaming protocol to leverage the transmission benefits afforded by parallel QUIC streams <del> as well exercising options for flexible loss recovery.  Applying QUIC to HAS via HTTP/3 has not yet yielded generalized improvements in throughput.  One reason for this is that sending segments down a single QUIC stream still allows head-of-line blocking to occur. </del> <ins> as well exercising options for flexible loss recovery. </ins> 1.1.3. <del> Internet delivered media today has protocols optimized for ingest and separate protocols optimized for distribution.  This protocol switch in the distribution chain necessitates intermediary origins which re- </del> <ins> Some live media architectures today have separate protocols for ingest and distribution, for example RTMP and HTTP based HLS or DASH. Switching protocols necessitates intermediary origins which re- </ins> package the media content.  While specialization can have its <del> benefits, there are gains in efficiency to be had in not having to re-package content.  A goal of MOQT is to develop a single protocol </del> <ins> benefits, there are efficiency gains to be had in not having to re- package content.  A goal of MOQT is to develop a single protocol </ins> which can be used for transmission from contribution to distribution. A related goal is the ability to support existing encoding and packaging schemas, both for backwards compatibility and for

Related discussion:
text: Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.