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?