Code change:
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

Related discussion:
text: A publisher MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object <del> ID is less than or equal to a previously sent Object ID within a given group on that stream. </del> <ins> ID is less than or equal to a previously sent Object ID with the same Group ID. </ins> <del> 7.4.2. </del> <ins> 7.3.2. </ins> <del> When a stream begins with "STREAM_HEADER_GROUP", all objects on the </del> <ins> When a stream begins with "STREAM_HEADER_PEEP", all objects on the </ins> stream belong to the track requested in the Subscribe message <del> identified by "Subscribe ID" and the group indicated by "Group ID". All objects on the stream have the "Publisher Priority" specified in the stream header. </del> <ins> identified by "Subscribe ID" and the peep indicated by 'Group ID' and "Peep ID". </ins> <del> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". </del> <ins> All Objects received on a stream opened with "STREAM_HEADER_PEEP" have an "Object Forwarding Preference" = "Peep". </ins> <del> To send an Object with "Object Forwarding Preference" = "Group", find the open stream that is associated with the subscription and "Group ID", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </del> <ins> To send an Object with "Object Forwarding Preference" = "Peep", find the open stream that is associated with the subscription, "Group ID" and "Peep ID", or open a new one and send the "STREAM_HEADER_PEEP". Then serialize the following fields. </ins> The Object Status field is only sent if the Object Payload Length is zero.