Author: [fill in your name and email address]
Status: Draft
Created: [fill in the date when the UIP was created in the form YYYY-mm-dd]
A short (~200 word) description of the technical issue being addressed.
The motivation is critical for UIPs that want to change the Unit-e protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the UIP solves.
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Unit-e platforms.
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
All UIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The UIP must explain how the author proposes to deal with these incompatibilities.
A proposal MUST have a reference implementation before it can move from
Draft to Proposed. The terms "reference implementation" and
"proof-of-concept" can be used interchangeably here. The point is that the idea
has gone through a phase of implementation so that it is a tested idea, and
issues which only can be found when actually trying to implement it have been
found and addressed.
It is better to finish the specification and rationale first and reach consensus on it before writing code, though.
This document and all its auxiliary files are dual-licensed under CC0 and MIT.