RFC 5139: A Complete Civic Address Is Not Presence Proof

Summary

RFC 5139 replaces the original PIDF-LO civic format with a richer XML vocabulary derived partly from the DHCP civic-address model.
Road, section, branch, building, unit, floor, room and seat fields can preserve distinctions that a flat street address loses.
A schema-valid address proves a representation passed one contract; it does not prove that a person or device occupies the place now.
Language-tagged variants should remain separate civic-address blocks, and language preference may choose presentation without resolving conflicting facts.
XML token processing collapses ordinary whitespace, so the lexical input and the value delivered to an application can differ.
Multiple location chunks need evidence of common source, time and determination method before they may be treated as one compound location.
Completeness is not freshness: a copied directory record may be detailed and stale, while a recent measurement may be coarse.
Authenticated provenance identifies an asserter; it does not make the asserted civic components true.
Civic precision implies an uncertainty region rather than a unique geospatial point, and omitted uncertainty never means zero uncertainty.
PIDF-LO privacy rules, recipient authorization, purpose, retention and onward disclosure are independent of address syntax.
LoST validation or SIP conveyance can prove routing stages, not target presence, dispatch correctness or responder arrival.
Leadership should require a receipt chain from observation through policy, mapping, call handling and outcome, without allowing one clean XML object to impersonate the whole chain.

The seductive completeness of a room number

Suppose an emergency workflow receives a civic object containing a country, province, municipality, named road, road section, building, floor and room. A dashboard marks every field green. The schema validates. The language tag is recognized. A service endpoint is returned.

The record looks more certain than a latitude-and-longitude estimate with an uncertainty radius. Yet the target may have moved ten minutes earlier. The room may come from an employee directory while the floor comes from network configuration. The road name may have been selected from a preferred-language variant after a tie. The service mapping may be valid for the address and still irrelevant to the caller's actual position.

RFC 5139 solves a real coordination problem. RFC 4119's original civic form lacked address components needed in different countries. RFC 4776 had already assembled a broader civic vocabulary for DHCP. RFC 5139 brings that vocabulary into PIDF-LO, adds a hierarchy for complex thoroughfares, supports language and script metadata, and narrows some value spaces. A recipient can now distinguish a main road from a section, a branch from a sub-branch, and a building from a unit or seat.

That precision belongs to the description. It says nothing by itself about the observation event. XML cannot tell whether the address was sensed, configured, copied, inferred, cached or selected by a user. The most dangerous promotion is therefore grammatical completeness becoming physical authority: “all fields present” quietly turns into “target present.”

The article's governing rule is simple. Every time the claim changes—from address syntax to place identity, from place identity to current presence, from presence to authorized disclosure, and from disclosure to operational outcome—the evidence must change with it.

Road hierarchy is not decorative metadata

RFC 5139 adds RD, RDSEC, RDBR and RDSUBBR because roads are not organized uniformly. One street number may repeat in several sections. Two small streets may share a name and become distinguishable only through the larger road each meets. A flat “street” string can discard precisely the distinction an application needs.

House number applies to the most specific road element present: sub-branch before branch, branch before section, section before primary road. Directionals and road qualifiers apply to the primary road, while a branch's own qualifier belongs in that branch value. The older A6 element remains for a country's administrative structure but must no longer be reused as the street name.

These rules make parsing and interpretation less arbitrary. They do not make the values authoritative. A producer can place a wrong house number under the correct branch. Two datasets can model the same local convention differently. A country guide can give A1 meaning that a generic implementation does not know. ISO country and subdivision codes constrain form and vocabulary, not the accuracy of one instance.

Operational evidence should preserve the ordered components rather than flatten them for convenience. It should also record the profile and registry versions used. A geocoder result must retain the candidates it considered, the fields it ignored or normalized, and whether it produced one match only because the dataset lacked alternatives. A unique database row is not necessarily a unique physical place.

The relevant acceptance test is not “does the example parse?” It is whether independently implemented producers and consumers preserve the same hierarchy for real local addresses, including repeated numbers, branches, sub-branches, rural forms, post-office boxes and building-internal detail. A shared field name creates a common question. It does not guarantee a common answer.

Language selection can hide a conflict

RFC 5139 permits xml:lang on language-bearing elements. Country and place type are treated as language-neutral under their respective registries. The separate script field from RFC 4776 is omitted because a language tag can include a script subtag. A civic-address block should use one language, or a consistent combination; several localized descriptions of the same place should be carried as separate blocks in the same tuple.

This is more than presentation polish. Local address forms can contain officially different names, scripts, abbreviations and ordering conventions. Preserving variants lets a local responder read one form while a remote system uses another. But a tag proves only that a producer labelled a value with a language or script. It does not establish that two forms refer to the same place.

Conversion from DHCP exposes the boundary. RFC 4776 can repeat an element in different languages or scripts; the XML form allows one instance of each element per civic-address block. Conversion may therefore create one block per language and replicate language-neutral components. If a receiver's preference is known, one representation can be assembled by weighting values. When weights tie, no preference matches, or same-language values conflict, the specification permits an arbitrary selection.

Arbitrary is a valid interoperability fallback. It is not conflict resolution. A system that stores only the selected variant erases the fact that another value existed. Later investigators cannot tell whether the winning string was preferred, tied, unsupported or contradictory. The receipt should preserve every candidate, its tag, the preference list, the weighting result and any conflict.

Do not normalize multilingual addresses into a single “canonical” string merely because a search index wants one key. Use a stable place identifier only after a competent authority or verified local process has established the equivalence. Language matching can select what to show; it cannot manufacture sameness.

The parser changes whitespace before the application sees it

RFC 5139 changes civic values from XML Schema string to token. Ordinary whitespace is normalized and collapsed before a processor delivers the value. Several line-broken or multiply spaced lexical forms can therefore become the same application value. A character reference can preserve a space where that distinction is necessary.

This improves consistency for addresses formatted across XML lines. It also creates an evidence boundary. A signature over bytes, a stored raw document, a DOM value and a database string may not be the same object. A diagnostic that records only the database field cannot prove what was received; a capture that records only raw XML cannot prove what the application compared.

The schema also allows extension elements from other namespaces and arbitrary attributes. That is sensible extensibility, but “valid against RFC 5139” does not mean every participating component understood every extension. A gateway may retain an unfamiliar element while a routing application ignores it. Another may reject it under a local profile. Both behaviors need explicit receipts.

For high-consequence use, log the immutable original, parser and schema versions, resulting component values, extension handling, warnings and rejected content. Treat any normalization that changes a routing-relevant value as an event. Never let a generic “schema valid” badge hide which information was collapsed or discarded.

A location description needs an observation story

RFC 5491 clarifies how PIDF-LO should represent one or several locations. A location belongs to a target, comes from a source, is created by a determination method, and may be delivered through a separate configuration protocol. Those nouns are not interchangeable.

When a civic and a geodetic description form one compound location, the chunks need a common source, common time and common determination method. Without that receipt, a precise room field from a static facilities database cannot safely refine a recent network-derived area. The two facts may both be correct in isolation and false in combination.

Timestamp handling is equally important. Completeness has no monotonic relationship with freshness. A long address may be cached for months; a coarse network location may have been observed seconds ago. Movement, reassignment, office changes, temporary seating and stale device configuration all break the assumption that detail implies currency.

The evidence record should therefore bind target identity, source identity, method, acquisition interface, observation time, issue time and expiry. If a target is a device used as a proxy for a person, that proxy relationship must be stated rather than assumed. If a user enters an address manually, the record should say so. If DHCP supplies it, preserve the network context and configuration lifetime. If a directory supplies it, preserve the directory revision and who controls updates.

An authenticated envelope can protect origin and integrity in transit. RFC 7378's trustworthy-location analysis makes the limit explicit: authentication can tell a recipient which source made an assertion, while the source can still be mistaken, compromised or describing a different object. Provenance allows accountability. It is not a truth machine.

Precision is not certainty

RFC 7459 describes location as an estimate. For civic addresses, uncertainty is implicit in the area represented by the most precise trustworthy component. Country is coarser than city; building is coarser than room; room may still cover a substantial space. An address can also omit a fine component because it was unavailable, unnecessary or deliberately withheld.

Missing uncertainty data does not mean no uncertainty. Nor does the presence of a seat field make the seat occupied. Precision describes the granularity of the assertion; confidence describes how likely the target is within the implied area; freshness describes when the observation applied. These are three different dimensions.

Geocoding introduces another transformation. A civic string can yield no match, several candidates, a centroid, an entrance or a rooftop point. Reverse geocoding can choose administrative boundaries differently from the original source. A service that compresses this into one pair of coordinates hides the candidate set and dataset assumptions.

Applications should retain the civic object alongside any derived geometry, with the geocoder version, candidate count, matching score, selected feature and uncertainty. A geospatial point derived from a room address should not pretend that the room itself was measured. Conversely, a point inside a building should not silently acquire a room number from the nearest directory record.

This is where a thin standard protects autonomy. RFC 5139 standardizes address components without ordering every local authority, responder or mapping provider to share one database. Local systems can interpret local address practice. Their decisions become defensible only when the transformation and its evidence remain visible.

Privacy is not an attribute of the XML grammar

Location can expose home, work, worship, health, association and movement. PIDF-LO therefore carries usage rules, and the broader GEOPRIV architecture assigns roles to the target, rule maker, location server and recipient. The fact that a recipient can parse a room or seat does not mean the recipient may receive, retain or retransmit it.

RFC 6772 allows policy to transform location detail. A recipient may receive a reduced civic description even when the source holds finer information. In that case, omitted fields can prove policy enforcement rather than data failure. A later system that “enriches” the record from another database may undo the intended privacy boundary.

Authorization must bind recipient, purpose, permitted precision, retention, onward disclosure and revocation. It should be evaluated at dereference or delivery time, not inferred from possession of a URI or prior access. Logs should avoid reproducing full locations into systems with broader readership than the operational service itself.

Data locality adds a separate question. A country code describes the location assertion; it does not declare where the record is stored, which jurisdiction governs the recipient, or where processing occurred. Treating an address field as a sovereignty label confuses subject geography with control of data.

The irreversible risk is secondary use. Once precise civic history has been copied into analytics, tickets and backups, a later policy change cannot reliably retrieve every replica. Collection restraint and field-level disclosure are therefore stronger controls than promising deletion after the fact.

Routing is a later decision, not a semantic upgrade

LoST can validate a civic location and map a service plus location to a service URI. SIP can convey or reference location information. These mechanisms are essential to emergency-service architectures, but each produces its own bounded receipt.

A LoST response can show what mapping server answered, which service was requested, what location was submitted, whether validation found missing or invalid components, which URI and boundary were returned, and when the mapping expires. It cannot prove the target occupies that address. A SIP message can prove that location was conveyed or dereferenced under a policy; it cannot prove the downstream endpoint dispatched the correct resource.

The outcome chain continues through call acceptance, caller interaction, dispatch interpretation, local address knowledge, unit selection, travel and arrival. A perfectly structured civic object can fail at any later stage. A sparse object can succeed because a trained operator resolves ambiguity. Protocol receipts and human outcomes should be connected, not collapsed.

Tests should therefore run full scenarios: stale but complete address; fresh but coarse address; conflicting language variants; branch and road sharing a name; withheld room detail; multiple geocoder candidates; unauthorized recipient; expired mapping; policy-constrained dereference; and successful mapping followed by operational failure. The system passes only when each stage reports what it actually knows.

RFC 5139 is valuable because it makes the first part of this chain less lossy. The mature deployment is the one that does not reward that improvement by asking the format to prove more than it can.

The Address Was Complete. The Person Might Not Be There.

Why it matters

Summary

The seductive completeness of a room number

Road hierarchy is not decorative metadata

Language selection can hide a conflict

The parser changes whitespace before the application sees it

A location description needs an observation story

Precision is not certainty

Privacy is not an attribute of the XML grammar

Routing is a later decision, not a semantic upgrade

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing