I'm very happy to see the charter being updated — thank you to the chairs, ADs, and the WG for driving it forward.
Just FWIW, draft-opik-quic-qmux-00 <https://datatracker.ietf.org/doc/draft-opik-quic-qmux/> is available and open for discussion. Aside from the name change, this draft is an updated version of the QUIC-on-Streams <https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams> draft. Please let the authors know what you think. Thank you in advance. 2025年10月9日(木) 2:31 The IESG <[email protected]>: > The QUIC (quic) WG in the Web and Internet Transport of the IETF has been > rechartered. For additional information, please contact the Area Directors > or > the WG Chairs. > > QUIC (quic) > ----------------------------------------------------------------------- > Current status: Active WG > > Chairs: > Matt Joras <[email protected]> > Lucas Pardue <[email protected]> > > Assigned Area Director: > Gorry Fairhurst <[email protected]> > > Web and Internet Transport Directors: > Gorry Fairhurst <[email protected]> > Mike Bishop <[email protected]> > > Mailing list: > Address: [email protected] > To subscribe: https://www.ietf.org/mailman/listinfo/quic > Archive: https://mailarchive.ietf.org/arch/browse/quic/ > > Group page: https://datatracker.ietf.org/group/quic/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ > > The QUIC WG originated the specifications describing version 1 of > QUIC, a UDP-based, stream-multiplexing, encrypted transport protocol. > > The WG acts as the focal point for any QUIC-related work in the IETF. > It is chartered to pursue work in the areas detailed below: > > 1. The first area of work is maintenance and evolution of the existing > QUIC specifications: > > * Maintenance and evolution of the QUIC base specifications that > describe its invariants, core transport mechanisms, security and > privacy properties, loss detection and recovery, congestion control, > version and extension negotiation, etc. > > * Maintenance and evolution of the existing QUIC extensions > specified by the WG. > > * Specification of new versions of QUIC. > > WG adoption of work items falling into this first area of work > needs to be strongly motivated by existing or ongoing production > deployments of QUIC at scale, and needs to carefully consider its > impact on the applications that have adopted QUIC as a transport. > > 2. The second area of work is supporting the deployability of QUIC, > which includes specifications, such as specification of a logging > format and operation with load balancers; and informational documents > such as applicability and manageability statements, and more. > > 3. The third area of work is the specification of new extensions to > QUIC. > > * The WG will primarily focus on extensions to the QUIC transport > layer, i.e., extensions to QUIC that have broad applicability to > multiple application protocols. > > * The WG may also publish Informational documents that > publicly document deployed proprietary extensions or to enable > wider experimentation with proposed new protocol features. > > 4. The fourth area of work is the specification of how QUIC stream > multiplexing and other application-oriented extensions (e.g. Datagram) > can be adapted to work over a reliable and bidirectional byte stream > substrate. When the substrate is insecure, TLS will be the default > security provider; no effort will be made to enable unprotected > communication without a security provider. Substrates must provide > congestion-management capabilities applicable to their deployment > environments. > > Specifications published by the QUIC WG Specifications will be > published on the Standards Track providing they can demonstrate > sufficient maturity. > > Specifications describing how new or existing application protocols > use the QUIC transport layer, called application protocol mappings > below, need not be specified in the QUIC WG, although they can. The > QUIC WG will collaborate with other groups that define such > application protocols that intend to use QUIC. New application > protocol mappings might require QUIC extensions and it may be > efficient to define these alongside the mapping specifications. Groups > that define application protocols using QUIC, or extensions to QUIC in > support of those protocols, are strongly requested to consult with the > QUIC WG and seek early and ongoing review of and collaboration on > proposals. This is intended to reduce the possibility of duplicate > work and/or conflicts with other extensions. > > Defining new congestion control schemes is explicitly out of scope for > the WG. However, new QUIC extensions that support development and > experimentation with new congestion control schemes may fall under > the third area of work. > > The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the > QPACK header compression scheme. These specifications are now > maintained in the HTTP WG. > > Milestones: > > - QUIC Acknowledgement Frequency to IESG > > - Reliable Stream Resets to IESG > > - Qlog documents to IESG > > - Multipath Extension to QUIC to IESG > > Sep 2021 - QUIC-LB: Generating Routable QUIC Connection IDs to IESG > > - QUIC Retry Offload to IESG > > > > -- Kazuho Oku
