Code change:
scenarios where the object size can be larger than maximum datagram size for the session, the Object will be dropped. <del> 7.4. </del> <ins> 7.3. </ins> <del> When multiple objects are sent on a stream, the stream begins with a stream header message and is followed by one or more sets of serialized object fields.  If a stream ends gracefully in the middle of a serialized Object, terminate the session with a Protocol Violation. </del> <ins> When objects are sent on streams, the stream begins with a stream header message and is followed by one or more sets of serialized object fields.  If a stream ends gracefully in the middle of a serialized Object, terminate the session with a Protocol Violation. </ins> <del> A publisher SHOULD NOT open more than one multi-object stream at a time with the same stream header message type and fields. </del> <ins> A publisher SHOULD NOT open more than one stream at a time with the same stream header message type and fields. </ins> TODO: figure out how a relay closes these streams <del> 7.4.1. </del> <ins> 7.3.1. </ins> When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message

Related discussion:
text: I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments