The standards landscape

SpecSpec: ISO 32000-2ISO 32000-2SpecSpec: ETSI EN 319 142-1ETSI EN 319 142-1SpecSpec: RFC 3161RFC 3161SpecSpec: WCAG 2.2WCAG 2.2

At a glance

A PDF engine does not answer to one document. It answers to a small federation of standards, written by different bodies, that reference one another. This page maps that federation as NextPDF tracks it. It also shows the path a clause takes from “a standard says so” to “the engine does so, and a test proves it.”

It is written for a senior engineer who needs to know which document governs a behavior before deciding whether NextPDF’s reading of it is one they can defend.

Why this matters

“PDF support” is a claim that hides a question: support of what, exactly? The core syntax is ISO 32000-2. Signatures route through ETSI. Timestamps are an IETF protocol. The HTML and CSS the engine renders are W3C. The cryptography underneath is NIST. Accessibility of the output is W3C again.

If a library treats those as one undifferentiated blob, you cannot reason about a failure. When a validator rejects a signed invoice, the useful first question is not “is the PDF broken?” It is “which standard’s clause was not met, and on which side?” To ask that question, you need a map that names the bodies and an honest account of how a clause becomes behavior.

The short version

• NextPDF tracks five standards bodies. ISO owns the format. ETSI owns the European signature profiles. IETF owns the wire protocols (timestamps, crypto primitives by reference). W3C owns HTML, CSS, and the accessibility criteria. NIST owns the approved cryptographic algorithms.
• These documents form trails, not a list: a single signed-PDF capability walks ISO → ETSI → IETF → NIST, each layer normatively referencing the next.
• A clause does not become behavior by being read. It becomes behavior by being paraphrased and cited, mapped to a requirement, implemented, and pinned by a test. The page that describes the behavior says so with its evidence level.
• When a clause is mandatory, it carries a normative keyword (a shall, a must). NextPDF treats those keywords as the contract. A should is a recommendation it documents as such, not as a guarantee.

How NextPDF approaches it

The federation, not a blob

ISO 32000-2 is the center. It defines what a conforming file is. A conforming file must adhere to every requirement of the document, while being free to omit any feature the document does not explicitly require SpecSpec: ISO 32000-2, §6ISO 32000-2 §6. It also sets the obligation on a writer: anything NextPDF creates or amends in a file must conform to the format and stay consistent with the elements already there SpecSpec: ISO 32000-2, §6ISO 32000-2 §6. That single clause is why the engine refuses to emit a structurally inconsistent incremental update. It is not a NextPDF preference. It is the format’s own rule.

From that center, ISO 32000-2 points outward. Its signature handling is defined “by means of reference” to the ETSI EN 319 142 series for PAdES. ETSI in turn references IETF RFC 3161 for the timestamp token, and the NIST FIPS series for the hash and signature algorithms. A capability is therefore a path through several documents, each of which is normative for its own layer.

1. Step 1 of 5: ISO 32000-2 §12.8 signaturesISO 32000-2 §12.8 signatures
2. Step 2 of 5: ETSI EN 319 142-1 PAdES baselineETSI EN 319 142-1 PAdES baseline
3. Step 3 of 5: RFC 3161 timestamp tokenRFC 3161 timestamp token
4. Step 4 of 5: NIST FIPS 180-4 hash strengthNIST FIPS 180-4 hash strength
5. Step 5 of 5: WCAG 2.2 tagged outputWCAG 2.2 tagged output

The standards trail a single long-term-validatable signed PDF traverses: ISO defines the container and points to ETSI for the signature profile; ETSI requires an IETF timestamp; the cryptographic primitives are NIST-approved; the rendered output is held to W3C accessibility. Each arrow is a normative reference, not a loose association.

How a clause becomes behaviour

The dangerous version of standards work is reading a clause and then writing code from memory. NextPDF’s path is deliberately longer, because the longer path is the one you can audit:

1. RetrieveThe clause is read from the standard, not from memory.
2. CiteIt is paraphrased and pinned with a chunk digest, never quoted.
3. ClassifyIts keyword (shall / should / may) sets whether it is a contract or a recommendation.
4. MapThe obligation becomes a concrete engine requirement.
5. ImplementThe requirement is built into the pipeline.
6. PinA test holds the behaviour against drift.
7. TagThe page that describes it declares its evidence level.

The path from a normative clause to a tested engine behaviour: retrieve and cite the clause, classify its obligation by its normative keyword, map it to an engine requirement, implement it, pin it with a test, and tag the documenting page with its evidence basis. A clause that stops before the test is a claim, not a behaviour.

The “classify” step is where most ambiguity is settled. Specifications encode their requirement levels in keywords: the well-known MUST, SHALL, SHOULD, MAY family. The meaning of those keywords is fixed by the IETF requirement-key-word convention, updated to clarify that only the uppercase forms are normative, and then layered on each specification’s descriptive prose SpecSpec: RFC 2119RFC 2119 SpecSpec: RFC 8174RFC 8174. NextPDF reads a shall as a hard boundary the engine does not cross, and a should as a recommendation it follows and documents as a recommendation — never as a promise. That distinction is the difference between an honest capability statement and an over-claim.

Conformance is graduated, not binary

“Conformant” is rarely one bit. The signature standards are leveled — the European long-term-with-archival profile, for instance, exists specifically to add timestamp tokens that keep a signature validatable long after it was created SpecSpec: ETSI EN 319 122-1, §6ETSI EN 319 122-1 §6. This is a strictly stronger claim than a bare baseline signature. The accessibility standard is the same shape: a conformance level is reached only by satisfying every success criterion at that level, and a claim states the level it actually reached SpecSpec: WCAG 2.2, §5.2.1WCAG 2.2 §5.2.1. NextPDF therefore states the profile and the level, not an unqualified “compliant”.

Human-factors note:Human-factors note

The standards trail is rendered as an ordered, captioned figure, not a decorative graphic, because a reader has to be able to follow the references in sequence and a screen reader has to announce them in that same order. The arrows between specs are decoration. The meaning is carried entirely by the spec names and the caption, which is the trail’s text equivalent. This is the same reasoning that governs every diagram in Insider_: order and meaning live in the markup, never in the color or the connector.

Practical example

You do not run the standards landscape; you read it to decide what to ask the engine for. Concretely, a long-term-validatable signing call is a statement about which point on the trail you need:

examples/36-sign-pades-b-b-and-b-t.php

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\DigitalSigner;
use NextPDF\Security\Signature\SignatureLevel;

// The signature level is a coordinate on the ISO -> ETSI -> RFC trail.
// PAdES B-B is the ETSI baseline CMS SignedData the Core engine produces;
// B-T adds an RFC 3161 timestamp, and B-LT/B-LTA add the DSS and document
// timestamps that keep a signature validatable after the certificate
// expires. The level you name is the point on the trail you are asking for.
$certInfo = CertificateInfo::fromFiles(
    certPath: 'signer-cert.pem',
    keyPath: 'signer-key.pem',
);

// The functional signing path is the direct two-phase signing engine.
// (Document::setSignature() records intent but its writer seam is not yet
// wired and fail-fasts on output — see the PadesOrchestrator docblock.)
$signer = new DigitalSigner(
    certInfo: $certInfo,
    level: SignatureLevel::PAdES_B_B,
);

$result = $signer->sign(file_get_contents('agreement.pdf'));

printf(
    "PAdES %s CMS: %d bytes, timestamp=%s\n",
    SignatureLevel::PAdES_B_B->value,
    $result->getSize(),
    $result->hasTimestamp() ? 'yes' : 'no',
);

Naming PAdES_B_LTA rather than a bare baseline is not a performance knob. It is a decision about how far down the standards trail the obligation reaches. B-LT and B-LTA pull in the DSS and archival-timestamp layers and require the enterprise LTV package at runtime. Rather than silently degrading, the engine refuses to pretend a lower level delivers a higher one.

Common misconception

The trap is reading “NextPDF is standards-compliant” as a single, total guarantee. It is not, and no honest engine offers one. Compliance is per standard, per clause, and per level. NextPDF targets the PDF 2.0 baseline, named PAdES profiles, and stated accessibility levels — each scoped, each cited. A claim without a clause and a level behind it is marketing, and Insider_ does not print it.

The second, subtler trap is assuming a normative should is a promise. It is a recommendation. NextPDF documents recommendations as recommendations. The engine’s guarantees are built from the shall clauses, and the difference is load-bearing.

Limits and boundaries

This page is the map, not the territory. It does not enumerate every clause NextPDF implements, and it is not a conformance certificate. Per-behavior proof lives on the topic page that owns the behavior, with that page’s own evidence level — for example PDF 2.0: what changed for the format delta.

The standards landscape also moves. New editions ship. References are updated. A clause cited here is pinned to the corpus snapshot recorded in this page’s citations. When an upstream standard is revised, the citation is re-validated against the new clause, not assumed to carry over. Where this page names a Premium-tier capability, it does so at the level of which standard it answers to, never at the level of internal mechanism.

Related docs

• PDF 2.0: what changed — the concrete ISO 32000-2 delta that the format layer of this map points at.
• Documentation as a product — why the discipline of mapping clauses to behavior is treated as engineering.
• Citation discipline — the rule that decides how a clause is cited here, and what an evidence level means.

Glossary

• Standards body — an organization that publishes a specification (ISO, ETSI, IETF, W3C, NIST). Each owns a different layer of the PDF stack.
• Normative clause — a requirement in a standard, identified by its keyword (shall/must for mandatory, should for recommended, may for optional).
• Standards trail — an ordered chain of specifications a single capability traverses, where each document normatively references the next.
• Conformance level — a graduated tier of compliance (an ETSI baseline profile, a WCAG level). A claim states the level actually reached, not an unqualified “compliant”.
• PAdES — PDF Advanced Electronic Signatures, the ETSI EN 319 142 family of signature profiles that ISO 32000-2 references for PDF signing.