# QUIC version 1 is done

The base-drafts repository is the historical home of the QUIC version 1
specifications that were written by the IETF QUIC Working Group.

The set of documents are:

* [QUIC: A UDP-Based Multiplexed and Secure Transport](https://tools.ietf.org/html/draft-ietf-quic-transport)
* [Version-Independent Properties of QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants)
* [Using TLS to Secure QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls)
* [QUIC Loss Detection and Congestion Control](https://tools.ietf.org/html/draft-ietf-quic-recovery)
* [Hypertext Transfer Protocol Version 3 (HTTP/3)](https://tools.ietf.org/html/draft-ietf-quic-http)
* [QPACK: Header Compression for HTTP/3](https://tools.ietf.org/html/draft-ietf-quic-qpack)


**All of the documents have been approved for publication as RFCs. We will no
longer consider design changes or substantial editorial changes unless they
relate to severe security, interoperability or deployment problems. See [Post-IESG
Process](#post-iesg-process) below for further information**

**The QUIC Working Group welcomes discussion about new versions of QUIC, and
new extensions to QUIC. See [Engaging with the QUIC
community](#engaging-with-the-quic-community) for guidance**

**Be aware that all contributions fall under the "[NOTE WELL](#note-well)" terms
outlined below and our [Code of Conduct](#code-of-conduct) applies.**

## Post-IESG Process

The consensus of the QUIC Working Group is reflected in the QUIC version 1
documents, which has been confirmed through the IETF Last Call and IESG review
stages. The goal of the Post-IESG process is to minimize the risk of changes
invalidating the established consensus in these documents. Consequently, design
changes will no longer be considered unless they relate to severe security,
deployment or implementation problems. If you believe you have identified such a
problem, please raise the issue on the [Working Group mailing
list](https://www.ietf.org/mailman/listinfo/quic) with a clear marking in the
`Subject:` line e.g. "New Issue ...".

Any change will be subject to careful review and discussion, which might involve
the editors, chairs, Working Group, and our Area Director.
After this review and discussion, errata may need to be filed for the published RFCs,
or the Working Group may otherwise address such valid issues.
# Engaging with the QUIC community

The scope of work in the QUIC Working Group is described in our
[charter](https://datatracker.ietf.org/wg/quic/about/) and it extends beyond the
development of the documents held in this repository. Anyone is welcome to
contribute to the QUIC Working Group; you don't have to join the Working Group,
because there is no "membership" -- anyone who participates in the work **is** a
part of the QUIC Working Group.

Before doing so, please familiarize yourself with our
[charter](https://datatracker.ietf.org/wg/quic/about/). If you're new to IETF
work, you may also want to read the [Tao of the
IETF](https://www.ietf.org/tao.html).

## Following Discussion

The Working Group has a few venues for discussion:

* We plan to meet at all [IETF meetings](https://www.ietf.org/meeting/) for the
  foreseeable future, and possibly hold interim meetings between them as
  required. Agendas, minutes, and presentations are available in our [meeting
  materials repository](https://github.com/quicwg/wg-materials) and the
  [official proceedings](https://datatracker.ietf.org/wg/quic/meetings/).

* Our [mailing list](https://www.ietf.org/mailman/listinfo/quic) is used for
  most communication, including notifications of meetings, new drafts, consensus
  calls and other business, as well as issue discussion.

* We maintain several repositories in our GitHub organization
  [Github](https://github.com/quicwg/). Specific issues are discussed on the
  relevant issues list. If you don't want to use Github to follow these
  discussions, you can subscribe to the [issue announce
  list](https://www.ietf.org/mailman/listinfo/quic-issues).

* The [quicdev Slack](https://quicdev.slack.com/) is used for more realtime
  communication, typcially amongst implementers, operators and researchers.
  Contact the [WG chairs](quic-chairs@ietf.org) for an invitation. Note that
  discussions on Slack are subject to the contribution guideline described in
  this document.

To be active in the Working Group, you can participate in any of these places.
Most activity takes place on the mailing list, but if you just want to comment
on and raise issues, that's fine too.

## Code of Conduct

The [IETF Guidelines for Conduct](https://tools.ietf.org/html/rfc7154) applies to all Working Group
communications and meetings.


## NOTE WELL

Any submission to the [IETF](https://www.ietf.org/) intended by the Contributor for publication as
all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF
activity is considered an "IETF Contribution". Such statements include oral statements in IETF
sessions, as well as written and electronic communications made at any time or place, which are
addressed to:

 * The IETF plenary session
 * The IESG, or any member thereof on behalf of the IESG
 * Any IETF mailing list, including the IETF list itself, any working group
   or design team list, or any other list functioning under IETF auspices
 * Any IETF working group or portion thereof
 * Any Birds of a Feather (BOF) session
 * The IAB or any member thereof on behalf of the IAB
 * The RFC Editor or the Internet-Drafts function
 * All IETF Contributions are subject to the rules of
   [RFC 5378](https://tools.ietf.org/html/rfc5378) and
   [RFC 8179](https://tools.ietf.org/html/rfc8179).

Statements made outside of an IETF session, mailing list or other function, that are clearly not
intended to be input to an IETF activity, group or function, are not IETF Contributions in the
context of this notice.

Please consult [RFC 5378](https://tools.ietf.org/html/rfc5378) and [RFC 8179](https://tools.ietf.org/html/rfc8179) for details.

A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in
Best Current Practices RFCs and IESG Statements.

A participant in any IETF activity acknowledges that written, audio and video records of meetings
may be made and may be available to the public.