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 <aylward.edw...@gmail.com> wrote: >> *Subject:* Proposal: Integrating DAAP Functionality into QUIC >> >> *To:* quic-cha...@ietf.org >> *Cc:* quic@ietf.org >> *From:* Ed Aylward aylward.edw...@gmail.com >> *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: aylward.edw...@gmail.com >> DAAP GitHub: https://github.com/ELF-GUARD/DAAP/ >> ORCID: 0000-0003-0313-6993 >>
