| --- |
| name: Formal RFC |
| about: Submit a formal Request For Comments for consideration by the team. |
| title: '' |
| labels: rfc, discussion |
| assignees: '' |
| |
| --- |
| |
| [NOTE]: # ( ^^ Provide a general summary of the RFC in the title above. ^^ ) |
| |
| # Introduction |
| |
| ## Abstract |
| |
| [NOTE]: # ( Provide a 1-to-3 paragraph overview of the requested change. ) |
| [NOTE]: # ( Describe what problem you are solving, and the general approach. ) |
| |
| ## Requirements Language |
| |
| [NOTE]: # ( Do not alter the section below. Follow its instructions. ) |
| |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in |
| [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.txt). |
| |
| ## Terminology |
| |
| [TIP]: # ( Provide a list of any unique terms or acronyms, and their definitions here.) |
| |
| --- |
| |
| # Detailed Description |
| |
| [NOTE]: # ( Describe the solution being proposed in greater detail. ) |
| [NOTE]: # ( Assume your audience has knowledge of, but not necessarily familiarity ) |
| [NOTE]: # ( with, the CouchDB internals. Provide enough context so that the reader ) |
| [NOTE]: # ( can make an informed decision about the proposal. ) |
| |
| [TIP]: # ( Artwork may be attached to the submission and linked as necessary. ) |
| [TIP]: # ( ASCII artwork can also be included in code blocks, if desired. ) |
| |
| # Advantages and Disadvantages |
| |
| [NOTE]: # ( Briefly, list the benefits and drawbacks that would be realized should ) |
| [NOTE]: # ( the proposal be accepted for inclusion into Apache CouchDB. ) |
| |
| # Key Changes |
| |
| [TIP]: # ( If the changes will affect how a user interacts with CouchDB, explain. ) |
| |
| ## Applications and Modules affected |
| |
| [NOTE]: # ( List the OTP applications or functional modules in CouchDB affected by the proposal. ) |
| |
| ## HTTP API additions |
| |
| [NOTE]: # ( Provide *exact* detail on each new API endpoint, including: ) |
| [NOTE]: # ( HTTP methods [HEAD, GET, PUT, POST, DELETE, etc.] ) |
| [NOTE]: # ( Synopsis of functionality ) |
| [NOTE]: # ( Headers and parameters accepted ) |
| [NOTE]: # ( JSON in [if a PUT or POST type] ) |
| [NOTE]: # ( JSON out ) |
| [NOTE]: # ( Valid status codes and their definitions ) |
| [NOTE]: # ( A proposed Request and Response block ) |
| |
| ## HTTP API deprecations |
| |
| [NOTE]: # ( Provide *exact* detail on the API endpoints to be deprecated. ) |
| [NOTE]: # ( If these endpoints are replaced by new endpoints, list those as well. ) |
| [NOTE]: # ( State the proposed version in which the deprecation and removal will occur. ) |
| |
| # Security Considerations |
| |
| [NOTE]: # ( Include any impact to the security of CouchDB here. ) |
| |
| # References |
| |
| [TIP]: # ( Include any references to CouchDB documentation, mailing list discussion, ) |
| [TIP]: # ( external standards or other links here. ) |
| |
| # Acknowledgements |
| |
| [TIP]: # ( Who helped you write this RFC? ) |
