> On 3. Oct 2022, at 23:59, Martin Duke <[email protected]> wrote: > > I'm late to this discussion, but if the need is a protocol that delivers > streams without encryption, SCTP (or SCTP over UDP) is a reasonably > well-vetted choice that would appear to meet the requirements. It certainly > sounds superior to asking people to invent a new protocol. Using SCTP-AUTH you can choose which part of the protocol data you want to be authenticated.
Best regards Michael > > (Which is not to say that the suggestions to making QUIC work in this use > case are unworkable) > > On Mon, Oct 3, 2022 at 11:38 AM Lucas Pardue <[email protected]> > wrote: > Hi Phillip, > > On Mon, 3 Oct 2022, 19:13 Phillip Hallam-Baker, <[email protected]> wrote: > I think we have to actually build a prototype of a transactional-first > transport, then build some applications over it and only then look to see > whether/how we might re-use QUIC. > > That is how I originally worked on HTTP, I build applications using HTTP as a > transport, one of which was the first Webmail service, those allowed me to > discover the need for content length and start working on connection > keepalive and framing. > > And we need to build any such system around the capabilities of modern > programming languages which support threads and asynchronous methods. > Otherwise we just end up trapped in subordination type interactions and don't > progress beyond RPC. > > What I am saying is, let me build something, then take a look at it and tell > me if/how to build it using QUIC. > > In case I was unclear, I think building something and revisitng later sounds > like a good approach. Look forward to seeing your progress > > In the meantime, and tangentially, I think its important to we provide a > consistent reminder that QUIC is very unopinionted about the applications on > top. This has been the case for years. I suspect many application protocols > that already exist would straightforwardly map to QUIC. We have RFCs that do > this, many I-Ds either individual or adopted by WGs, and I'm aware of many > protocol mappings that are defined outside the IETF - either openly > documented or private. > > Should future evolution of QUIC provide opportunity for alternative > (re)mappings that people think would be useful, that is entirely possible and > supported. Extension like that should probably also add a section that > extends the applicability document to aid designers and implementers. > > Cheers > Lucas > > > > > On Mon, Oct 3, 2022 at 1:19 PM Lucas Pardue <[email protected]> > wrote: > Hi Behcet, > > > On Mon, Oct 3, 2022 at 5:56 PM Behcet Sarikaya <[email protected]> wrote: > Hi Christian, > > I quickly glanced through RFC 9250 which defines DoQ and references ALPN in > RFC 7301. > Agree with Philip that DoQ does not define something that is independent of > HTTP. > > Will it come one day, we don't know? > Behcet > > DoQ is an application mapping over QUIC. ALPN is an extension to TLS. DoQ > might use a transactional model that maps to bidirectional streams but that > is the full extent of similarities to HTTP; there is no normative dependency. > > RFC 9000 was written carefully to describe the interface that > application-data-bearing streams can provide to applications. This is not > related to HTTP, QUIC is independent of HTTP. Indeed, QUIC on its own means > pretty much nothing. It needs an application mapping protocol. The > recently-published applicability draft, RFC 9308 [1], is specifically written > to aid designers or implementers of such mappings. Randy might find RFC 9308 > informative if wishing to pursue QUIC as a transport substrate for the OT > application layer traffic. > > Cheers > Lucas > > [1] - https://www.rfc-editor.org/rfc/rfc9308.html > >
