156 lines
4.8 KiB
Plaintext
156 lines
4.8 KiB
Plaintext
|
= RFC-0000: :bulb: Title :bulb:
|
||
|
:toc: preamble
|
||
|
:toclevels: 3
|
||
|
ifdef::env-github[]
|
||
|
:tip-caption: :bulb:
|
||
|
:note-caption: :information_source:
|
||
|
:important-caption: :heavy_exclamation_mark:
|
||
|
:caution-caption: :fire:
|
||
|
:warning-caption: :warning:
|
||
|
endif::[]
|
||
|
|
||
|
.**RFC Template**
|
||
|
|
||
|
.Metadata
|
||
|
[cols="1h,1"]
|
||
|
|===
|
||
|
| RFC
|
||
|
| 0000
|
||
|
|
||
|
| Title
|
||
|
| :bulb: Title :bulb:
|
||
|
|
||
|
| Sponsor
|
||
|
| :bulb: Link to github user page (if multiple, comma separated on one line). Example: link:https://github.com/username[User Name], link:https://github.com/username2[User Name 2] :bulb:
|
||
|
|
||
|
| Status
|
||
|
| Not Submitted :information_source:
|
||
|
|
||
|
| Type
|
||
|
| :bulb: Standards, Informational, or Process :bulb:
|
||
|
|
||
|
| Created
|
||
|
| :bulb: Date (YYYY-MM-DD) :bulb:
|
||
|
|
||
|
|===
|
||
|
|
||
|
== Abstract
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Give a short (200 word) description of the technical issue addressed.
|
||
|
|
||
|
* Use present tense - describe what the proposal "does" (as if it were already done) not what it will do.
|
||
|
* Do not go into technical details, those go in the Specification section.
|
||
|
* Do not talk about history or why this needs to be done, that is part of Motivation section.
|
||
|
====
|
||
|
|
||
|
== Specification
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Provide a detailed specification what is being proposed. Be as technical and
|
||
|
detailed as needed to allow new or existing developers to reasonably understand
|
||
|
the scope/impact of an implementation.
|
||
|
|
||
|
* Use present tense - describe what the proposal "does" (as if it were already done) not what it will do.
|
||
|
* Do not discuss alternative designs that were rejected, those belong in the Reasoning section.
|
||
|
* Avoid in-depth discussion or justification of design choices, that belongs in the Reasoning section.
|
||
|
====
|
||
|
|
||
|
== Motivation
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Explain why the existing code base or process is inadequate to address the problem that the RFC solves.
|
||
|
This section may also contain any historal context such as how things were done before this proposal.
|
||
|
|
||
|
* Do not discuss design choices or alternative designs that were rejected, those belong in the Reasoning section.
|
||
|
====
|
||
|
|
||
|
== Reasoning
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Explain why particular design decisions were made.
|
||
|
Describe alternate designs that were considered and related work, e.g. how the feature is supported in other systems.
|
||
|
Provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
|
||
|
|
||
|
* Use sub-headings to organize this section for ease of readability.
|
||
|
* Do not talk about history or why this needs to be done, that is part of Motivation section.
|
||
|
====
|
||
|
|
||
|
== Backwards Compatibility
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Describe any incompatibilities and their severity.
|
||
|
Describe how the RFC proposes to deal with these incompatibilities.
|
||
|
|
||
|
If there are no backwards compatibility concerns, this section may simply say:
|
||
|
There are no backwards compatibility concerns related to this proposal.
|
||
|
====
|
||
|
|
||
|
== Security
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Describe the security impact of this proposal.
|
||
|
Outline what was done to identify and evaluate security issues,
|
||
|
discuss of potential security issues and how they are mitigated or prevented,
|
||
|
and how the RFC interacts with existing permissions, authentication, authorization, etc.
|
||
|
|
||
|
If this proposal will have no impact on security, this section may simply say:
|
||
|
There are no security risks related to this proposal.
|
||
|
====
|
||
|
|
||
|
|
||
|
== Testing
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
If the RFC involves any kind of behavioral change to code give a summary of how
|
||
|
its correctness (and, if applicable, compatibility, security, etc.) can be
|
||
|
tested.
|
||
|
|
||
|
In the preferred case that automated tests can be developed to cover all
|
||
|
significant changes, simply give a short summary of the nature of these tests.
|
||
|
|
||
|
If some or all of changes will require human interaction to verify, explain why
|
||
|
automated tests are considered impractical. Then summarize what kinds of test
|
||
|
cases might be required: user scenarios with action steps and expected
|
||
|
outcomes. Might behavior vary by platform (operating system, servlet
|
||
|
container, web browser, etc.)? Are there foreseeable interactions between
|
||
|
different permissible versions of components?
|
||
|
Are any special tools, proprietary software, or online service accounts
|
||
|
required to exercise a related code path (Active Directory server, GitHub
|
||
|
login, etc.)? When will testing take place relative to merging code changes,
|
||
|
and might retesting be required if other changes are made to this area in the
|
||
|
future?
|
||
|
|
||
|
If this proposal requires no testing, this section may simply say:
|
||
|
There are no testing issues related to this proposal.
|
||
|
====
|
||
|
|
||
|
== Prototype Implementation
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Link to any open source reference implementation of code changes for this proposal.
|
||
|
The implementation need not be completed before the RFC is accepted
|
||
|
but must be completed before the RFC is given "final" status.
|
||
|
|
||
|
RFCs which will not include code changes may omit this section.
|
||
|
====
|
||
|
|
||
|
== References
|
||
|
|
||
|
[TIP]
|
||
|
====
|
||
|
Provide links to any related documents. This will include links to discussions
|
||
|
on the mailing list, pull requests, and meeting notes.
|
||
|
====
|
||
|
|
||
|
|
||
|
|