Subject: [Taps] FW: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system)

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 11 Aug 2020 12:40:12 +0000

Maybe this is also interesting for taps as a reference...

On 10.08.20, 22:35, "QUIC on behalf of Dirkjan Ochtman" <[email-masked] on behalf of [email-masked]> wrote:

    On Fri, Aug 7, 2020 at 12:57 AM Martin Duke <[email-masked]> wrote:
    > On this subject, (speaking as individual) I think it would be useful to define a QUIC application API. SCTP did one (https://datatracker.ietf.org/doc/rfc6458/) and the idea that an application would have to be written separately for each quic implementation is silly.

    For what it's worth, for the hyper library (the most popular HTTP
    library in the Rust ecosystem) we're trying to define a set of Rust
    traits (abstract interfaces) that cover the basic QUIC API insofar as
    H3 support needs it.

    https://github.com/hyperium/h3/blob/master/design/PROPOSAL.md#4-public-api

    Kind regards,

    Dirkjan

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Aug 2020 10:05:37 -0500

> Maybe this is also interesting for taps as a reference...

I sure hope so!

Best,

Spencer

>
> On 10.08.20, 22:35, "QUIC on behalf of Dirkjan Ochtman" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     > On this subject, (speaking as individual) I think it would be useful
> to define a QUIC application API. SCTP did one (
> https://datatracker.ietf.org/doc/rfc6458/) and the idea that an
> application would have to be written separately for each quic
> implementation is silly.
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>