Summary

  • “Well-formed” admits an XML document to parsing; it does not prove schema validity, semantic correctness, signature coverage, authorization or a committed operation.
  • A defensible protocol record keeps received octets, parser configuration, external inputs, infoset, validation, signature references, application decision and observed outcome as separate receipts.

The parser returned success. The request still failed.

That sequence is not an edge case in which XML contradicted itself. It is the normal boundary between syntax and protocol. A parser can establish that start and end tags are balanced, characters are legal and the document obeys XML's core construction rules. It cannot decide whether a customer may close an account, whether a routing update belongs to this peer, or whether the signed node is the node the application later executes.

RFC 3470, published in January 2003 as Best Current Practice 70, was written for protocol designers who had already chosen XML. It did not declare XML the preferred representation for all IETF work. Its durable contribution is more austere: name the transformations between wire bytes and application behavior, and do not give one transformation the authority of the entire chain.

The first refusal must be complete

Well-formedness is the admission gate. RFC 3470 says an implementation must not take a malformed document and partially interpret the portion it happens to understand. Retransmission or abort may be appropriate, depending on the protocol; proceeding with a fragment can leave two peers believing different state was created.

That strict rule still grants little authority to a well-formed message. It says the concrete syntax can be parsed. The resulting XML Information Set is an abstract view of elements, attributes, character information and namespace properties. It is already one step removed from the received octets.

Encoding declarations, byte order, line endings, attribute quoting and entity references can affect the concrete record while disappearing or normalizing in the parsed view. An incident report that preserves only the tree cannot always reproduce what a signature engine, gateway or different parser saw.

The first receipt therefore contains the octet hash, transport envelope, media type, declared or detected encoding and observation time. The next contains the parser identity, version, configuration and a strict well-formedness result. Combining them into “XML accepted” erases the point at which interpretation began.

Validation narrows the grammar, not the world

A schema can reject a missing field, an unexpected child or a value outside a declared type. That is valuable. It is not the same as knowing that the field is true, current or permitted.

RFC 3470 notes that DTDs, XML Schema and other validation formalisms express different constraints, while protocol specifications inevitably retain additional syntactic and semantic requirements in prose. No schema language proves a caller's authority, a resource's present state or the success of a downstream transaction.

Defaults expose an especially awkward boundary. A validating processor can add a default attribute declared by a DTD or schema even though those bytes never crossed the network. A packet capture and an application log may then show different apparent messages without either record being fabricated. Protocols are advised to avoid that ambiguity.

The validation receipt must name the schema or profile, its version and resolution source. It must record whether defaults were applied and what application-visible tree resulted. “Schema valid” without those coordinates is not reproducible evidence.

A namespace is a vocabulary label, not a badge of office

Namespaces let XML vocabularies coexist. Their URI-shaped names are identifiers; they are not automatically instructions to fetch policy, nor proof that the sender controls the institution suggested by a domain name.

The syntax also contains a trap for hurried reviewers. A default namespace applies to unprefixed element names. It does not apply to unprefixed attribute names. An element and the bare attribute written inside it can therefore belong to different naming contexts.

A protocol must define how names map to meaning and authority. It must also say what happens to an unknown extension: reject it, ignore it, preserve it, forward it, or fail because it is mandatory to understand. Perfectly well-formed XML can still leave that decision unspecified.

Processing instructions and comments are poor hiding places for normative behavior. RFC 3470 recommends that normal protocol processing be able to ignore them and that they not define the protocol's extension mechanism.

The parser may be able to reach farther than the sender

External entities, schemas and relative references can cause interpretation to depend on material outside the message. The dependency may change after the original octets have been captured. It may also ask the parser to make a network request from a location the sender could not directly reach.

RFC 3470 advises protocol designers to avoid entity declarations and tells implementations handling untrusted XML not to allow arbitrary access through external references. The five predefined XML entities and numeric character references remain ordinary syntax; a remotely fetched object is a different authority surface.

xml:base adds another coordinate. If a transport, container and document each supply a possible base URI, the protocol must define which one resolves a relative link. Without that rule, two conforming components can fetch different resources.

The record needs the external-access policy, every resolved URI, the exact fetched bytes or a proof that fetching was disabled, and the base-URI precedence. Otherwise replay means “parse it again in today's environment”, not “reconstruct yesterday's decision”.

Canonicalization does not make semantics identical

RFC 3076 defines Canonical XML to produce a reproducible serialization from an XML node-set. It can remove some legal syntactic variation. RFC 3275 then describes XML Signature references and transforms.

Those mechanisms add receipts; they do not collapse the chain. The verifier must show which nodes a reference selected, which transforms ran, which canonicalization algorithm and parameters applied, and whose key authenticated the result. A valid signature over one subtree does not authenticate an unsigned sibling that the application later treats as decisive.

Nor does cryptographic validity grant permission. Identity, integrity and authorization answer different questions. A properly signed cancellation can still target the wrong account, arrive after a deadline or violate a state-machine rule.

Canonicalization is also not a licence to invent a private XML subset. RFC 3470 warns that ad-hoc restrictions create interoperability failures. If a protocol needs one representation for comparison or signatures, it should specify the common algorithm and retain the pre-transform evidence.

Whitespace can become data

Humans read indentation as presentation. XML processors expose character information unless a protocol or schema establishes a different handling rule. Reformatting a document can therefore change a value.

Attribute order, by contrast, is not semantically significant, and attribute values can be normalized. A system that hashes source order while another hashes a canonical node-set is not measuring the same object. Neither “it looked identical” nor “the tree was equal” identifies the signature input.

This is why an XML protocol needs concrete rules for whitespace, mixed content, element order, attribute use and extension preservation. Style conventions are not enough once independent implementations exchange state.

A safe grammar can meet unsafe code

XML provides no built-in confidentiality, integrity, authentication or authorization. Its parser is also executable code facing attacker-controlled structure. RFC 3470 calls parser implementations a soft target and highlights malformed input, buffer failures, entity misuse and resource consumption.

The security receipt includes parser limits, recursion and expansion controls, external-access policy, time and memory ceilings, and failure behavior. A document can conform to the grammar while inducing unacceptable work. A parser can also contain a vulnerability even when the protocol's design is sound.

RFC 8996 later updates RFC 3470's security context by deprecating TLS 1.0 and TLS 1.1. That update does not convert transport encryption into proof of XML semantics or application authorization.

Fourteen receipts for one operation

Start with received bytes and encoding. Record the parser and its configuration. Preserve strict well-formedness and complete failure. Capture entity expansion, base URI and external-resource behavior, then the resulting infoset.

Next name the schema/profile and validation result. Record namespace and extension dispatch. Preserve canonicalization parameters and the exact signature reference set, followed by the authenticated identity.

Only then record application semantic checks, authorization and prior state. A committed state transition gets its own receipt. The authenticated downstream or user-visible outcome comes last. Where interoperability is claimed, replay with external access disabled and with another conforming implementation.

“The XML was valid” cannot replace that sequence because it does not say which kind of validity was observed.

Evidence boundary

This article does not diagnose a named parser, service or incident. It does not claim that schemas are weak, signatures are futile, or every XML processor makes external requests. It separates their bounded powers.

It also does not repeat BTW's existing YANG/XML analysis, which owns the questions of effective YANG trees, defaults, schema revisions, mount context, datastore transition and network effect. RFC 3470 addresses the more general protocol boundary between XML octets and application action.

Heng Lu's minimum-initial-specification and running-code principles are disclosed editorial lenses. They favour a small interoperable wire contract, local implementation choice beyond it, and receipts from the running path. They are not deployment measurements.

The narrow conclusion is enough: a parser can admit a document without granting it meaning, authority or effect. Systems become auditable when each grant has its own evidence.

Sources