Summary
- RFC 5261 proves that an ordered operation located one unique node in the supplied XML tree and produced the defined mutation; it does not prove that the tree was the intended current base.
- A defensible patch receipt must bind base bytes and version, selector context, every intermediate state, failure point, transaction policy, semantic validation and final publication observation.
The entitlement changed perfectly in yesterday’s document
A billing service received a small XML diff: replace the price under the account whose identifier matched a selector. The processor found exactly one node, replaced it and returned a clean patched document. The operation was mechanically correct.
The target snapshot had been superseded minutes earlier. Another update had changed the account’s plan and moved the price under a different entitlement. The patch did not conflict because RFC 5261 does not itself bind a diff to an application version. It simply operated on the supplied tree.
This is the governing distinction. Deterministic mutation is not optimistic concurrency control. A unique target is not necessarily the intended current object.
A selector locates a node, not an institutional identity
Every operation carries sel, a restricted XPath selector that must identify one unique target. Zero or multiple matches are errors. Names, wildcards, predicates, text values, positions and, when supported by the document model, id() can narrow the result.
Those rules answer “which node in this tree?” They do not answer “which approved account revision?” A positional path can shift after an insertion. An attribute can be reused. An ID is only as durable as the schema, parser and application lifecycle that define it.
The receipt therefore needs both the selector and the matched preimage: base hash, expanded namespaces, resolved path and node hash. Recording only the selector turns a reproducible computation into an ambiguous historical claim.
Operations create a sequence of new targets
Add, replace and remove are ordered. After one operation succeeds, the patched document becomes the independent target for the next. That means a sibling insertion can move the positional coordinate used by a later operation. Removal can join adjacent text nodes. Whitespace directives can intentionally remove formatting nodes.
Order is not incidental metadata. It is part of the program. Two diffs containing the same operations in a different order can select different nodes or produce different documents.
An error does not define a universal rollback
RFC 5261 says an operation that cannot be fulfilled unambiguously creates an error and that further processing is hardly sensible. It defines precise error elements for unlocated nodes, invalid node types, namespace failures, unsupported IDs and other conditions.
It does not impose one storage transaction on every application using the framework. A later failure may occur after earlier intermediate documents have been produced in memory; whether anything durable was written, rolled back or exposed belongs to the surrounding protocol and implementation.
“Patch failed” is therefore not a complete state report. It must be paired with the failed operation number, last successful intermediate hash and explicit commit or rollback result.
Namespace spelling and namespace identity are different
Prefixes are locally scoped. A diff and target may use different prefixes for the same namespace URI. RFC 5261 resolves them in context and can rewrite prefixes when adding content. It also specifies behavior that differs from ordinary XPath default-namespace expectations in defined cases.
A prefix change can be representation-preserving. It can still surprise downstream code that improperly treats spelling as identity. The patch processor can satisfy the XML model while an application with a faulty prefix assumption changes behavior. Protocol correctness and consumer correctness remain separate.
Canonical equivalence is not business equivalence
The framework uses canonical XML with comments to define logical equivalence for its deterministic processing goal. It carefully handles text and whitespace because the XML data model does not permit adjacent text nodes.
Canonicalization does not certify application meaning. Replacing one policy value can preserve well-formedness, schema validity and canonical determinism while violating an entitlement rule, signature scope, workflow state or human approval. Those invariants live above the patch vocabulary.
Version history is deliberately left to the application
RFC 5261 notes that some applications may require complete version history, including superfluous changes, but mandates no universal behavior. It also warns that short positional selectors are fragile because insertions and removals change indexes.
That is not a defect. It is a boundary. Applications that need current-base guarantees must add an ETag, generation, source hash or other precondition. Applications that need atomicity must define commit semantics. Applications that need authorization must bind principal and scope.
The patch receipt
For consequential updates, preserve:
- target record identity, exact base bytes, hash, version, ETag or generation;
- diff bytes and hash, media type, charset, schema and authenticated principal;
- ordered operation number, selector text and expanded namespace bindings;
- matched node path, type and preimage hash;
- operation content and each intermediate document hash;
- error element, failed operation and last successful intermediate;
- rollback or commit policy and observed result;
- final document hash, schema and application-semantic validation; and
- storage acknowledgement, replication and reader-visible publication observation.
This receipt does not make the patch authorized. It prevents “the selector matched” from being promoted into “the intended current object was safely changed.”
Sources
- https://www.rfc-editor.org/rfc/rfc5261.html
- https://www.rfc-editor.org/rfc/rfc5261.txt
- https://www.rfc-editor.org/info/rfc5261/
- https://datatracker.ietf.org/doc/rfc5261/
- https://datatracker.ietf.org/doc/rfc5261/history/
- https://datatracker.ietf.org/doc/rfc5261/references/
- https://datatracker.ietf.org/doc/rfc5261/referencedby/
- https://www.rfc-editor.org/errata/rfc5261
- https://www.rfc-editor.org/rfc/rfc7351.html
- https://www.rfc-editor.org/rfc/rfc7303.html
- https://www.rfc-editor.org/rfc/rfc3629.html
- https://www.rfc-editor.org/rfc/rfc5262.html
- https://www.w3.org/TR/1999/REC-xpath-19991116/
- https://www.w3.org/TR/2001/REC-xml-c14n-20010315
- https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
- https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
- https://www.w3.org/TR/2006/REC-xml-20060816/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-the-agency-problem-at-the-core-of-internet-governance/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
