title	description
Contributing to HTTP	How to participate in the HTTP Working Group

Anyone can contribute to HTTP; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work, as outlined below, is part of the HTTP Working Group.

Before doing so, it's a good idea to familiarize yourself with our charter, and home page. If you're new to the IETF, you may also want to read an informal guide to the IETF process and the Tao of the IETF.

Be aware that all contributions fall under the "NOTE WELL" terms outlined below.

Contributing to Work in Progress
Proposing New Work
- Other Venues for HTTP Work
- Bringing Work to the IETF
Code of Conduct
NOTE WELL

Contributing to Work in Progress

Following Discussion

The HTTP Working Group has a few venues for discussion:

We have a session at most IETF meetings, and sometimes in between (called an "interim" meeting). See our meeting materials repository, and the official IETF proceedings for details.
Our mailing list (subscribe) is used for notifications of meetings, adoption of documents, consensus calls, issue discussion, and other business. It's not mandatory to subscribe, but you're likely to miss important things if you don't; also, note that e-mail sent to this list will be manually moderated (and thus delayed) if you are not subscribed.
We discuss most document issues on GitHub.

You can participate in any or all of these places.

Raising Issues

We use GitHub to track discussion items and their resolution. Before filing a new issue, please consider a few things:

Issues should be just that: issues with our deliverables, not proposals for new work, questions, or support requests.
There may be an existing duplicate issue, so please review the issues list first.
If you're not sure how to phrase your issue, please ask on the mailing list.

Issues can also be raised on the mailing list by clearly marking them as such (e.g., with New issue in the Subject: line).

Be aware that issues might be rephrased, changed in scope, or combined with others. If you feel that an important part of your original issue has been lost, please bring it up (on the issue or on the list).

Off-topic and duplicate issues will be closed without discussion. Note that commit comments will only be responded to with best effort, and may not be seen.

Resolving Issues

As in all IETF Working Groups, final consensus of the Working Group is determined during Working Group Last Call; consensus established during issue discussion provides a limited precedent, to prevent revisiting topics unnecessarily. Our issues list provides a mechanism for tracking those discussions and their outcomes.

Some issues might be labeled as editorial; they can be dealt with by the editor(s) without consensus or notification, and discussion will take place on the issue itself. If you believe an editorial issue is not purely editorial, please say so on the issue; the Chair(s) will make a determination.

The remaining open issues in the issues list are those that need Working Group discussion.

Issues can be discussed on the mailing list or the issues list. The editors can also propose resolutions to issues for the group's consideration by incorporating them into the draft(s).

When an issue is closed, it implies that the issue's proposed resolution is reflected in the draft(s). When a new draft is published, the issues that have been closed since the last draft will be highlighted in the draft's change notes and/or on the mailing list, to aid reviewers.

Note that whether or not an issue is closed does not necessarily reflect consensus of the Working Group; an issue's open/closed state is only used to organise our discussions. If you have a question or problem with an issue in the closed state, please say so (either on the issue or the mailing list).

Some issues might require an explicit consensus call; if consensus is achieved in this manner, the issue will be labeled with has-consensus. Reopening issues with has-consensus requires new information (in the judgement of the Chairs).

Pull Requests

We welcome pull requests, both for editorial suggestions and to resolve open issues. In the latter case, please identify the relevant issue.

Please do not use a pull request to open a new issue. Instead, file an issue and refer to it from the pull request.

Proposing New Work

If you'd like to propose a new HTTP extension (e.g., method, header, status code, HTTP/2 or HTTP/3 SETTINGS), it's best to first describe your use case on the mailing list. Often, there's an existing HTTP feature that can be used.

If a new extension is necessary, we usually discuss them in Internet-Draft form. However, if you're unfamiliar with that format, write down your proposal precisely but succinctly and send it to the mailing list.

If there is interest in the proposal, the Chairs will issue a Call for Adoption, where Working Group participants comment on whether or not they support adoption, and whether or not they might implement it.

Upcoming proposals and calls for adoption are tracked by the Chairs in the admin repository.

If the Chairs determine that there is consensus to adopt the document, the Working Group will start discussing it.

Once a draft is adopted, the Chairs will assign one or more editors to the document. Although this will sometimes be the same person(s) that made the original proposal, it might not be, for various reasons; it could be that an experienced editor is needed for a tricky draft, or your contribution as a participant, rather than a neutral editor, is judged more valuable. In any case, the Chairs will discuss editor selection with you before making an announcement.

The Editor(s) first task will be to upload an initial draft into a Working Group repository. If you're selected as an editor, the Chairs will be in touch with more details.

Other Venues for HTTP Work

There are other places inside and outside the IETF that are doing HTTP-related work. Depending on the nature of your proposal, you might consider taking your work to one of the following venues:

The HTTP APIs Working Group focuses on API-related HTTP extensions and similar specifications
The DISPATCH Working Group decides where it's most appropriate to take new work in the IETF's Applications and RealTime (ART) area. While you can come directly to the HTTP Working Group with a proposal, you can also take it there. Sometimes that can lead to starting a new Working Group (often for larger or more specialised work)
The WHATWG Fetch Specification defines the API for HTTP that browsers expose

Bringing Work to the IETF

There are a few things that are important to know when you bring work to the IETF.

First, when your draft is adopted by the Working Group change control -- that is, who determines what's in the specification -- passes from you to the IETF. That means that some things that you don't agree with might happen to it, and it might be published with things that you wouldn't have included (or without things that you would have kept).

That's because the document's content is determined by consensus of the Working Group, and then the IETF overall. Even though you started it, the document needs to reflect the community's input, and that takes primacy.

As a result, whenever a document is adopted it's considered a starting point -- i.e., nothing is "locked down". Of course, you will have ample opportunity to discuss any issues you have with proposed changes, and if you make a convincing argument, consensus should follow. However, it's important that you are able to accept that the document will change. If you just want it rubber-stamped, it's not appropriate to bring it to the IETF.

Why should you bring your document here, if you have to give up control? Not only will your work benefit from the broad review from many HTTP implementers and practitioners, but that community will also be more likely to implement and use an extension once it has gone through that process.

Code of Conduct

The IETF Guidelines for Conduct applies to all Working Group communications and meetings.

NOTE WELL

By participating in the IETF you agree to follow IETF processes and policies. This Note Well is a reminder of some of those policies.

IETF participants are expected to behave in a professional manner and extend respect and courtesy to their colleagues at all times (see RFC 7154: IETF Guidelines for Conduct and IETF Anti-Harassment Policy). If you have any concerns about behavior, please contact the Ombudsteam who have a duty of confidentiality and extensive powers to act, as set out in RFC 7776: IETF Anti-Harassment Procedures.
If you are aware that any IETF contribution (as defined in RFC 5378: Rights Contributors Provide to the IETF Trust) is covered by patents or patent applications that are owned or controlled by you, your employer or your sponsor, you must disclose that fact, or not participate in the discussion (see RFC 8179: Intellectual Property Rights in IETF Technology).
For detailed process information consult RFC 2026: Internet Standards Process and RFC 2418: IETF Working Group Guidelines and Procedures and updates to those.
The IETF routinely makes public written, audio, video, and photographic records of IETF activities, including your personal information as set out in the IETF Privacy Statement.

For advice, please talk to Working Group chairs or Area Directors.

Working Group Information

Discussion of this work occurs on the HTTP Working Group mailing list (archive, subscribe). In addition to contributions in GitHub, you are encouraged to participate in discussions there.

Note: Some working groups adopt a policy whereby substantive discussion of technical issues needs to occur on the mailing list.

You might also like to familiarize yourself with other Working Group documents.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!