# Template Document Brief
Rename or copy this file to match a real target document, then replace the project-specific placeholders. The common RFC structure below is already the default; specialize it instead of inventing a section plan from scratch.
## Mission
Draft `[replace: full document title]`.
This document is responsible for `[replace: the exact problem, protocol, model, or format this draft owns]`.
## Front matter
- Use the metadata defaults from `../draft-metadata.md`.
- Title: `[replace: exact title]`
- Stream / intended status: `[replace: stream and status]`
- Abstract anchor: `[replace: the one-sentence promise the abstract must make]`
- Special front-matter rule: `[replace: provenance sentence, naming convention, no special rule, or other constraint]`
## Exact scope
### In scope
- `[replace: the core protocol/model/format behavior this document must specify]`
- `[replace: the operations, messages, fields, or algorithms it must define]`
- `[replace: interoperability, parsing, validation, or generation behavior a clean-room reader must learn here]`
### Out of scope
- `[replace: topics owned by another document]`
- implementation-internal details not meant for the public draft
- deployment guidance, UI behavior, or local tooling workflow
## Default section skeleton for the draft
Use this as the starting outline unless the project has a strong reason to differ:
1. **Introduction**
2. **Conventions and Terminology**
3. **[Rename to the document's normative heart: Protocol / Format / Data Model / Procedure / Schema / etc.]**
4. **[Optional but expected when relevant] Validation, Error Handling, or Processing Rules**
5. **Security Considerations**
6. **IANA Considerations**
7. **References**, with normative and informative references kept distinct
8. **Appendices or examples** only when they add real interoperability value
## Required section expectations
| Section | Default expectation | Project-specific specialization |
| --- | --- | --- |
| Introduction | State the problem, applicability, and document boundary without trying to teach the whole system. | `[replace: what this introduction must clarify first]` |
| Conventions and Terminology | Import or define only the terms this document truly needs. If requirement keywords such as MUST or SHOULD appear, include the standard BCP 14 note. | `[replace: which terms are owned here versus imported]` |
| Protocol / format / data model core | This is the document's normative heart. Rename the heading to the real subject and fully specify the interoperable behavior it owns. | `[replace: the exact normative heart of the document]` |
| Validation / error handling / processing rules | State failures, limits, invariants, or receiver behavior when malformed or unsupported input appears. Omit only if the document genuinely has none. | `[replace: required failure modes or invariants]` |
| Security Considerations | Address the concrete security consequences of the specified behavior; do not leave this as generic boilerplate. | `[replace: security topics this draft must cover]` |
| IANA Considerations | Default to an explicit no-action statement unless the project really needs registrations, code points, registries, or media-type work. | `[replace: no-action statement or required registrations]` |
| References | The rendered draft is expected to separate normative from informative references. Start from `../references.md` and cite only what this document actually uses. | `[replace: any document-specific reference additions or exclusions]` |
| Examples / appendices | Use only observed, re-validated, or otherwise justified material; examples should not smuggle in unstated rules. | `[replace: examples, appendices, or none]` |
## Required clean-room capabilities
After reading this document alone or with its named dependencies, a competent reader should be able to:
- `[replace: parse, validate, or interpret something]`
- `[replace: generate or send something interoperable]`
- `[replace: handle an error path or corner case correctly]`
- `[replace: understand the dependency on another document or external RFC]`
## Dependencies and cross-references
- Depends on `[replace: document or external RFC]` for `[replace: terminology or mechanism]`.
- Must not redefine `[replace: concept owned elsewhere]`.
- Should cross-reference `[replace: other document/section]` when discussing `[replace: topic]`.
## Evidence and example policy
- Primary evidence should come from `[replace: canonical code/spec/trace/artifact surface]`.
- Public examples should come from `[replace: observed output, packet capture, exported object, etc.]`.
- If the document includes byte-counted, grammar-sensitive, or binary examples, note the exact render traps here.
- Record any must-test hard cases: `[replace: separator byte, whitespace edge, malformed input, version boundary, etc.]`.
## High-risk review traps
Call out the mistakes reviewers should actively look for.
- `[replace: ambiguity that tends to cause duplicate wording or wrong ownership]`
- `[replace: subtle rule that renderers or authors often misstate]`
- `[replace: historical or compatibility behavior that must be preserved or explicitly excluded]`
- `[replace: example pitfall that only shows up after rendering]`
## Completion bar for this brief
The brief is ready when a drafter can answer all of these without guessing:
- What exactly does this document own?
- Which sections are mandatory, and which heading carries the normative heart?
- Which sources govern each major claim?
- Which topics belong in another document instead?
- Which example or review traps must be re-checked before publication?