The capsule protocol was designed with this in mind. Receivers that don't know about the DATA capsule will treat it as an unknown capsule and stream it without buffering. Receivers that implement it will know that DATA is special. All we need is an "Updates: 9297" tag to override this MUST. David On Thu, Mar 7, 2024 at 9:27 AM Ben Schwartz <bemasc@meta.com> wrote: > > > On Mar 7, 2024, at 12:18 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> > wrote: > Hey, > > On Thu, 7 Mar 2024, 17:00 Ben Schwartz, <bemasc@meta.com> wrote: > > ... > > As an example of the complexity, note that all uses of the Capsule >> Protocol to date are "atomic": each capsule is expected to be buffered and >> processed as a whole. In this thread we've heard proposals to introduce >> new capsule types that the recipient must process in "streaming" fashion. >> This mix of atomic and streaming capsules is a new wrinkle in the Capsule >> Protocol. >> > > FWIW the capsule protocol spec highlights this and normatively recommends > streaming https://datatracker.ietf.org/doc/html/rfc9297#section-3.2-12. > > > I think that’s slightly different. Implementations SHOULDN’T buffer the > capsule “in the data stream”, but nothing there recommends against > buffering the message outside of the stream before processing it. > > By my reading, the “infinite capsule trick” proposed in this thread would > actually be malformed: > https://datatracker.ietf.org/doc/html/rfc9297#section-3.3-3. The sender > is supposed to know the exact length of each capsule before it is sent, so > capsules cannot really be streamed. > > —Ben >
Received on Thursday, 7 March 2024 18:13:59 UTC