One paragraph, plain English. Someone who reads only this paragraph should understand what’s being proposed.
Why does this need to exist? What’s broken / missing / painful without it? Who’s been asking for it? Cite discussions, issues, or real-world use cases.
Name the specific problem, not the general aspiration. “Users want better primitives” is not a motivation. “An XRAI scene can’t describe a recurring scheduled event without encoding it as repeated entity stamps, which breaks compression and round-tripping (discussion #42, issue #87)” is a motivation.
Exact schema, syntax, behavior. Include:
Be specific. Someone implementing this from your RFC alone should not need to ask follow-up questions.
At least three. Explain why you rejected each. If you haven’t considered alternatives, stop writing the RFC and consider some — the first idea is rarely the best.
What happens if we don’t ship this? Is there a workaround in existing spec? When does the workaround fall over?
What would this look like? Why did you reject it?
Same.
What ships + in what order:
Not every RFC touches every step. Call out which ones are skipped and why.
What don’t you know yet? Name them. Don’t pretend the design is done if it isn’t. Unresolved questions are a reason to delay an RFC to “Under review,” not to merge it with hidden gaps.
Does any existing format / spec / protocol do this well (or badly)? USD, glTF, Wikidata, schema.org, OpenXR, MPEG-SCENE, X3D — show your homework. An RFC that doesn’t cite prior art is an RFC that will reinvent a mistake.
What does this unlock that isn’t in scope for this RFC but might become another RFC later? Keep the list short — premature promises rot.
How will we know this was the right call? Concrete: “if a v1.2 runtime adopts this within 6 months + the conformance-corpus-bug count stays below X, we keep it. If not, revisit at v1.3 with an eye toward simplification.”