'Media over QUIC <https://datatracker.ietf.org/group/moq/about/>' is a WG that is standardizing an application layer optimized for media and other types of data that are better suited to publish/subscribe than HTTP/RPC.
MoQ might be of interest to you directly, but I mainly point it out because it's intended to either run over raw QUIC or over WebTransport (ideally over HTTP/3), which might be an approach worth adopting for your use cases? I'd be happy to provide more thoughts after reading the draft. Thanks, Ian On Sat, Jul 12, 2025 at 10:20 PM Lucas Pardue <[email protected]> wrote: > Hi Edward > > On Sat, Jul 12, 2025, at 16:48, Marten Seemann wrote: > > It’s difficult to provide meaningful feedback without access to the draft > itself, but my initial question would be: what’s the justification for > defining new QUIC frame types? In general, QUIC frames, aside from STREAM > and DATAGRAM, are intended to modify transport-layer behavior. Based on the > description, DAAP appears to be an application-layer protocol, and it seems > more appropriate for it to be layered on top of QUIC rather than extending > the transport itself. > > +1 Marten's points > > Generally, embedding non-transport capabilities into the transport layer > is an anti-pattern. Furthermore, there is no common QUIC API, which makes > exposing transport features that applications rely on a difficult task. > > I'd first encourage you to explore some options for running your protocol > over HTTP/3 or WebTransport. Both of which run over QUIC and provide clear > explanations of how QUIC streams or datagrams can be used to exchange > application protocol data. Then you might get a clearer idea what, if any, > inefficiences you see. > > Cheers > Lucas > > > On Fri, 11 Jul 2025 at 16:44, Edward Aylward <[email protected]> > wrote: > > *Subject:* Proposal: Integrating DAAP Functionality into QUIC > > *To:* [email protected] > *Cc:* [email protected] > *From:* Ed Aylward [email protected] > *Date:* July 11, 2025 > > ------------------------------ > > Dear Lucas and Matt, > > I hope you’re both doing well. > > My name is Ed Aylward, and I’m the author of *draft-aylward-daap-v2*, > which outlines the Distributed AI Accountability Protocol (DAAP). It’s a > framework designed to help maintain human oversight over autonomous AI systems > by requiring regular, verifiable communication with a designated authority. > > I’m reaching out to propose a new QUIC extension that would allow DAAP to > run natively over QUIC. The goal is to move beyond HTTP-over-TCP, embedding > DAAP’s core functions directly into the transport layer by defining: > > - > > New QUIC frame types for behavioral check-ins, policy updates, and > emergency signaling > - > > A TLS extension (daap_identity) to establish agent identity at the > start of the QUIC handshake > - > > Multiplexed streams to handle real-time control, telemetry, and > enforcement in parallel > > This integration would provide tighter security guarantees, better > performance, and more responsive control, especially valuable for > environments where speed, reliability, and accountability are critical. > > If the working group is open to reviewing this idea, either as a > contribution to QUIC or as an individual draft submission, I’d be happy > to share: > > - > > A working draft in the IETF format > - > > Notes on how the implementation maps to current QUIC capabilities > - > > Example use cases in sectors like robotics, edge AI, and smart > infrastructure > > Thanks for considering this. I appreciate your time and would welcome any > suggestions or guidance on next steps. > > Best regards, > *Edward Richard Aylward, Jr.* > Email: [email protected] > DAAP GitHub: https://github.com/ELF-GUARD/DAAP/ > ORCID: 0000-0003-0313-6993 > > >
