Requests for comments
A structured way to propose changes, compare alternatives, and preserve the reasoning behind OpenForex decisions.
Publication status
Published by the OpenForex Society, the standard-setting core of the OpenForex Foundation, as part of its established standards service to the open standards community.
Version
0.2.0
Last Updated
2026-09-24
When to write an RFC
Use an RFC when a proposal changes a standard's behavior, adds a compatibility requirement, changes governance authority, or introduces a consequential data or monetary policy. A spelling correction or link repair normally needs a focused patch instead.
No numbered RFC register or ratified RFC decision is included in this package. Do not invent an accepted RFC identifier to give a proposal authority.
Proposal structure
| Section | What reviewers need |
|---|---|
| Title and author | A specific problem and accountable proposer |
| Status and revision | Draft state and exact version under review |
| Motivation | Who encounters the problem and under which conditions |
| Proposed behavior | Concrete before-and-after behavior |
| Alternatives | Plausible options and reasons for the selection |
| Compatibility | Affected documents, implementations, and migration requirements |
| Evidence | Derivations, fixtures, experiments, or source references |
| Risks and unresolved questions | Known limitations and decisions still needed |
| Decision record | Review outcome and authorized publication reference |
Review workflow
Start with a draft linked to affected pages. Invite domain review through the official contribution channel when available. Incorporate feedback in a visible revision history. Separate resolved objections from questions still awaiting evidence.
A proposal can remain a draft, enter structured review, be revised, be withdrawn, or receive a recorded decision under the adopted governance process. An author marking a file Approved is not itself ratification.
Example of a well-scoped question
A proposal to reject stale oracle snapshots should define observation time, permitted age, configuration scope, and the resulting error. Include a fresh example, a boundary example, and an expired example. Explain how existing consumers migrate.
After a decision
Link the accepted proposal to the exact specification revision and effective conditions. Retain rejected or withdrawn proposals when they explain design choices, with their status clearly visible.
Use the page template, contribution workflow, and governance overview.
Sources & citation
- Material type
- Project reference
- Publisher
- OpenForex Society
- Source version
- 0.2.0
- Source-stated update
OpenForex Society. “Requests for comments.” Version 0.2.0. https://openforex.io/?page=seed-content%2Frfc-proposals%2Findex. Include your access date when citing.
Download the exact published MarkdownText fingerprint (SHA-256)
0abd84cdf81b6198258912e336948fc2810f1255c6fbb1559ea2082ceb3766dbThis identifies the downloadable text, not an independent approval or a permanent archived edition.
Referenced material (3)
- page templateProject reference
- contribution workflowProject reference
- governance overviewProject reference
Standards, implementation references and worked calculations identify their sources and publication status. Read our sourcing and corrections policy.