MIRs
MIR status terms
- Idea - An idea that is pre-draft. This is not tracked within the MIR Repository.
- Draft - The first formally tracked stage of an MIR in development. An MIR is merged by an MIR Editor into the MIR repository when properly formatted.
- Review - An MIR Author marks an MIR as ready for and requesting Peer Review.
- Last Call - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.
- Final - This MIR represents the final standard. A Final MIR exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
- Stagnant - Any MIR in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An MIR may be resurrected from this state by Authors or MIR Editors through moving it back to Draft.
- Withdrawn - The MIR Author(s) have withdrawn the proposed MIR. This state has finality and can no longer be resurrected using this MIR number. If the idea is pursued at later date it is considered a new proposal.
- Living - A special status for MIRs that are designed to be continually updated and not reach a state of finality. This includes most notably MIR-1.
MIR Types
MIRs are separated into a number of types, and each has its own list of MIRs.
Architecture (1)
Mailio ecosystem architecture, its components and interactions. Architecture ecompoases API definitions, dependant services, client/server communications.
Core (0)
Describes any change that affects most or all Mailio implementations, such as a change to the network protocol, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Mailio.
Components (4)
Core components encompass all custom made components required for Mailio ecosystem to function. This section contains all core components, whether for web interface of core/backend
Application Interface (3)
Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names.
Informational (1)
Describes a Mailio design issue, or provides general guidelines or information to the Mailio community, but does not propose a new feature. Informational MIRs do not necessarily represent Mailio community consensus or a recommendation, so users and implementers are free to ignore Informational MIRs or follow their advice.