Compliance
Shall, should, may: Reading a spec's verbs
A specification uses a small set of verbs to sort statements into two piles: what a vendor must do to claim compliance, and what it is free to do or skip.
A specification uses a small set of verbs to sort statements into two piles: what a vendor must do to claim compliance, and what it is free to do or skip. In most standards, shall marks a requirement, should marks a recommendation that can be departed from with a stated reason, and may marks a genuine option. The hard part is not the vocabulary but the reading: the same verb can carry different force depending on where it sits in a clause and what the clause is describing.
The discipline is not unique to PCI Express. Anyone who has tried to follow written instructions for a volunteer-run project knows the same problem: the difference between a rule and a suggestion is often the difference between a working result and a broken one. A practical magazine for church websites, The Church Web Review, deals with the same sorting problem when it tells a volunteer webmaster which accessibility fixes are non-negotiable and which are matters of taste. The parallel is useful because it shows why normative language exists at all: it lets a reader act without having to guess the author's intent.
What does shall commit a vendor to?
Shall is the strongest verb in the set. A statement containing shall is a requirement: an implementation that does not satisfy it is not conformant, no matter how well it performs otherwise. The commitment is not to a behaviour in the abstract but to the behaviour as described, including every condition attached to it. If a clause says that a device shall enter a given state within a stated time after a stated event, the vendor is committed to that state, that event and that time, and a reader may test all three.
Two consequences follow. First, shall statements are the ones a compliance test suite is built around; they are the clauses an implementer cannot negotiate away. Second, shall is not a synonym for important. A specification may contain a shall about a trivial detail and a should about a central one. The verb describes the obligation, not the significance of the subject matter.
A frequent misreading is to treat shall as a description of what good implementations happen to do. It is not a summary of practice; it is a boundary. Behaviour outside the boundary may still work, but it is not covered by the claim of conformance.
When is a should a requirement?
Should marks a recommendation. A vendor that follows it is doing what the specification prefers; a vendor that does not is still conformant, provided the choice is deliberate and its consequences are understood. The usual formulation is that there may exist valid reasons to ignore a particular item, but the full implications must be understood before a different course is chosen.
That wording is where the practical force of should lives. In a conformance review, a should is not a box to tick but a question to answer: why was it not followed, and what does the departure cost? A should becomes effectively binding in three situations. It becomes binding when another shall clause depends on it, so that ignoring it breaks a requirement elsewhere. It becomes binding when a profile or a procurement document elevates it, turning the recommendation into a contractual term. And it becomes binding in practice when the cost of departure falls on the other end of the link, for example when a receiver must handle a case the sender chose not to avoid.
A reader who treats every should as optional will produce an implementation that passes the letter of the specification and fails in the field. A reader who treats every should as a requirement will over-build and may reject conformant parts. The correct reading sits between the two and depends on context the clause itself often supplies.
How is a may read by an implementer?
May grants permission. It describes something an implementation is allowed to do, not something it is obliged to do and not something it is encouraged to do. A may clause is a statement about the space of legal behaviours: an implementation that exercises the option is conformant, and one that does not is equally conformant.
For an implementer, may clauses are where interoperability risk concentrates. If a sender may emit a particular encoding and a receiver may ignore it, then two conformant devices can still fail to work together unless both sides handle the case. This is why specifications often pair a may with a shall elsewhere: the option is real, but the obligation to cope with it is placed on the other party. Reading a may clause therefore means asking who else has to tolerate the choice.
May also appears in clauses about testability, where it signals that a behaviour is observable but not mandated. Such clauses are useful for diagnosis and should not be turned into acceptance criteria.
A table of verbs and their force
| Verb | What it commits a vendor to | How a reader treats it |
|---|---|---|
| shall | The described behaviour, under every stated condition | A requirement; the basis of a conformance claim and of a test |
| shall not | The absence of the described behaviour | A prohibition; a violation is a non-conformance |
| should | A preferred behaviour, departable with a stated reason | A recommendation; ask why it was not followed and what it costs |
| should not | A discouraged behaviour, departable with a stated reason | A recommendation against; same treatment as should |
| may | Nothing; it grants permission | An option; check who must tolerate it |
| can | Nothing normative; it states capability or possibility | Descriptive text, not a requirement |
Checklist for reading a requirement out of a clause
- Find the normative verb. If the clause contains no shall, should or may, it is probably explanatory text.
- Identify the subject. The obligation usually falls on a named component, not on the system as a whole.
- List the conditions. Every if, when and after in the clause narrows the requirement.
- Check the object. What exactly must be true, and is it observable?
- Look for cross-references. A clause that points elsewhere inherits the force of the clause it points to.
- Test the negation. If the opposite behaviour would also be conformant, the clause is not a requirement.
- Note the exceptions. A should with a listed exception is weaker than a should without one.
Common mistakes
- Reading shall as a description of typical practice rather than a boundary.
- Treating every should as optional, then discovering that a dependent shall clause fails.
- Treating every should as mandatory, and rejecting conformant parts.
- Reading may as encouragement, and building an option into a product as if it were required.
- Ignoring the conditions attached to a verb, so that a conditional requirement is applied unconditionally.
- Confusing can with may: can describes what is possible, may describes what is permitted.
- Assuming the verb carries the same force in every document. A procurement text may redefine should as a requirement, and a profile may tighten a base specification.
- The verbs are a contract between writer and reader. Read them as such, and a clause stops being ambiguous prose and becomes a statement about what an implementation owes and what it is free to choose.
The page behind these facts
The figures on this page are read from the source the text names, rfc-editor.org, consulted on September 6, 2026. How this desk reads a document, and what it does with a figure it cannot source, is set out in sources and method.