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.


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

Reply via email to