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 >> >> >> >
