Code change:
7.2. <del> An "OBJECT_STREAM" message carries a single object on a stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object". To send an Object with "Object Forwarding Preference" = "Object", open a stream, serialize object fields below, and terminate the stream. Subscribe ID: Subscription Identifier as defined in message- subscribe-req. Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by Subscribe ID, the subscriber MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. 7.3. </del> An "OBJECT_DATAGRAM" message carries a single object in a datagram. An Object received in an "OBJECT_DATAGRAM" message has an "Object

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