Template Document Brief

Rename or copy this file to match a real target document, then replace every bracketed placeholder.

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]
• Intended status/category: [replace: 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]
• [replace: implementation-internal details not meant for the public draft]
• [replace: deployment guidance, UI behavior, or local tooling workflow]

Required sections

Fill in the exact structure this document needs.

Section	Must cover	Primary evidence source
Introduction	[replace: what the reader must understand first]	[replace: source]
Terminology	[replace: terms this document owns or imports]	[replace: source]
Protocol / format / data model	[replace: the normative heart of the document]	[replace: source]
Validation / error handling	[replace: failures, limits, or invariants]	[replace: source]
Security considerations	[replace: the concrete security topics the draft must address]	[replace: source]
IANA considerations	[replace: registrations or explicit no-action statement]	[replace: source]
Examples / appendices	[replace: what examples or collected grammar are required]	[replace: source]

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?
• Which sources govern each major claim?
• Which topics belong in another document instead?
• Which example or review traps must be re-checked before publication?