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.
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 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.
We discuss most document issues on GitHub. If you don’t want to use Github to follow these discussions, you can subscribe to the issue announce list.
You can participate in any or all of these places.
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 Working Group 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.
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).
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.
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 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.
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:
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.
The IETF Guidelines for Conduct applies to all Working Group communications and meetings.
This is a reminder of IETF policies in effect on various topics such as patents or code of conduct. It is only meant to point you in the right direction. Exceptions may apply. The IETF’s patent policy and the definition of an IETF “contribution” and “participation” are set forth in BCP 79; please read it carefully.
As a reminder:
Definitive information is in the documents listed below and other IETF BCPs. For advice, please talk to WG chairs or ADs: