The standards landscape

Spec: ISO 32000-2 Spec: ETSI EN 319 142-1 Spec: RFC 3161 Spec: WCAG 2.2 Evidence: Standard-backed

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 Spec: ISO 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 Spec: ISO 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.

Step 1 of 5: ISO 32000-2 §12.8 signatures
Step 2 of 5: ETSI EN 319 142-1 PAdES baseline
Step 3 of 5: RFC 3161 timestamp token
Step 4 of 5: NIST FIPS 180-4 hash strength
Step 5 of 5: WCAG 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:

Retrieve The clause is read from the standard, not from memory.
Cite It is paraphrased and pinned with a chunk digest, never quoted.
Classify Its keyword (shall / should / may) sets whether it is a contract or a recommendation.
Map The obligation becomes a concrete engine requirement.
Implement The requirement is built into the pipeline.
Pin A test holds the behaviour against drift.
Tag The 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 Spec: RFC 2119 Spec: RFC 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 Spec: ETSI 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 Spec: WCAG 2.2, §5.2.1 . NextPDF therefore states the profile and the level, not an unqualified “compliant”.

What the evidence says

This page is Evidence: Standard-backed : each claim is anchored to a clause, paraphrased, and cited with a digest so the next reviewer can re-verify it against the source.

Layer	Body	Anchor clause (paraphrased)	What it governs in NextPDF
Format	ISO	A writer’s created or amended elements must conform and stay consistent Spec: ISO 32000-2, §6	The PDF the engine emits
Conformance	ISO	A conforming file meets all requirements; extra features are optional Spec: ISO 32000-2, §6	What “valid output” means
Signature profile	ETSI	The long-term-with-archival level adds timestamps for later validation Spec: ETSI EN 319 122-1, §6	The PAdES profile a signature targets
Trusted time	IETF	A timestamping service proves a datum existed before a time Spec: RFC 3161, §2	The document timestamp token
Cryptography	NIST	Approved hashes differ in the security strength they confer Spec: NIST FIPS 180-4, §1	The digest algorithm under a signature
Output access	W3C	A conformance level requires every criterion at that level Spec: WCAG 2.2, §5.2.1	Accessibility claims on rendered PDFs

The cited digests are recorded in this page’s citations frontmatter. None of the standards’ text is reproduced here. The rule that governs that choice is itself a page. See Citation discipline.

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:

<?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.

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.