Summary

  • The active ECRIT draft adds ordered planned-change polling, future-dated asOf validation and revalidateAfter advice to LoST. These mechanisms identify records that may change and let clients prepare replacements before an effective time.
  • The draft explicitly says identical future-date queries made at different times may return different answers. A future response reflects what the server knows now; it neither guarantees the later mapping nor proves that a client installed it.
  • A two-stage validation receipt should preserve preparation and cutover as separate observations. This is Daniel Kade’s editorial proposal, not an IETF requirement and not evidence of deployment.

Midnight changes the record, not the ground

Imagine a district annexed by a municipality at the first minute of a new month. A building does not move. Its latitude does not jump. Yet one civic address element that was empty or carried another value yesterday may need the municipality’s name today. A street renaming or renumbering can create the same split between physical continuity and administrative change.

That is the practical starting point of Validation of Locations Around a Planned Change. Revision 18 is an active Internet-Draft in the IETF’s Emergency Context Resolution with Internet Technologies working group. It is work in progress, not an RFC and not evidence that any operator has deployed the design.

The base protocol, RFC 5222, defines LoST: a client supplies location information and a service identifier, and a server returns service URIs and associated information. LoST can also validate a civic location. The response may say which address elements were recognized as valid, ignored or found invalid. RFC 5139 supplies the civic-location vocabulary used in the draft’s example.

A Location Information Server may hold many such records. Without notice of an impending administrative change, it can discover drift only by revalidating its database on some schedule. That schedule can be too slow for the cutover and unnecessarily expensive before it. The draft therefore gives a LoST server a narrow way to describe what it currently expects to change and when.

The governance problem is not whether planning is desirable. It is what the resulting evidence can honestly prove. A record prepared on Monday for a boundary expected to change on Friday belongs to Monday’s knowledge, even when the query asks about Friday.

The draft creates three different clocks

The first clock belongs to the planned-change feed. A separate REST/JSON interface exposes version discovery, polling and ChangeSet retrieval. A ChangeSet has an ordered identifier, an effective time and one or more partial locations. A client retains the last identifier it received and asks for later changes. The sequence gives the client a position in one server’s published stream.

The second clock belongs to asOf. A client can ask LoST to validate a record for a stated future date and time. The server answers with what it knows at query time should be in effect by that future point. When the answer is not for the current time, the response must echo asOf, and its mappings must be marked NO-CACHE.

The third clock belongs to ordinary revalidation. The proposed revalidateAfter element allows the server to advise when a client may wish to check again. Its NO-EXPIRATION value is carefully bounded: the server is not currently aware of a planned change that would affect the validation. It does not promise that no change will later be learned, and it does not abolish periodic revalidation for unplanned events.

These clocks answer different questions. The poll says, “What newer change notices does this server know after my retained position?” The future query says, “Given what this server knows now, how would it validate this record at that time?” The revalidation advice says, “When should I consider asking again?” None says, “The future event occurred exactly as planned and every downstream system adopted the new state.”

Flattening the clocks into one green status would discard the very uncertainty the draft preserves. It would also transfer authority. A server that publishes planned location data would appear to certify the client’s database execution, even though it never observed that execution.

A ChangeSet is a selector, not a verdict

Planned changes cannot be useful if they require the server to enumerate every full address. The draft instead defines partial locations: sets of location-element names, namespaces and values. A client compares the pairs with its own records. If all supplied pairs match, that client record may be affected. Fields omitted from the partial location do not participate in the match.

This is deliberately broad. A selector can identify a whole administrative subdivision regardless of street and house number, or one street regardless of building number. It turns a future boundary event into a tractable local search.

But “may be affected” is not a weak drafting accident. It is the correct evidence boundary. A match does not prove that every selected record must change. It does not prove the client constructed the right replacement. It does not prove the future validation answer will remain stable, or that the replacement reached the active database at the effective moment.

An operator therefore needs to retain both sides of the selection. On the server side: ChangeSet ID, effective time, partial-location pairs and interface version. On the client side: the matching rule, database snapshot, number and identities of candidate records, exclusions and any operator-approved exception. If the client records only “432 locations affected”, a later reviewer cannot tell whether a corrected street value narrowed the set, a schema interpretation widened it or a database filter silently omitted a region.

This is a familiar distinction in thin coordination. A shared format should transmit the smallest information needed for participants to interoperate. It should not pretend to decide every local consequence. Lu Heng’s Minimum Initial Specification principle is useful here: the common layer can carry ordered notices and deterministic fields while each operator remains responsible for its own activation decision and evidence.

The future answer is intentionally revisable

Section 4 of the draft states the limit directly. A server may learn about planned or unplanned changes at any time. Two requests made on different days with the same future asOf value can therefore produce different results. The server makes no guarantee about a later query of the same location.

This is not a flaw to be fixed with stronger wording. It is an honest account of knowledge over time. A municipal decision may be postponed. A street plan may be corrected. A dataset may arrive late. Another change may take effect before the original one. A server that cannot revise its future answer would turn early information into an irrevocable promise.

The NO-CACHE requirement protects the same boundary at the protocol level. It prevents a future mapping from being treated as durable routing state. The draft also says that a client wishing to contact a service is still expected to use LoST contemporaneously with that need. Preparing a record is not the same act as resolving the currently appropriate service.

This separation matters most because ECRIT works on systems supporting communication with relevant emergency response centres. The working-group charter also anticipates multiple regions, jurisdictions and independent delegations rather than one central authority. A clean evidence chain must therefore avoid two overclaims at once: location validation is not proof that an emergency communication completed, and a server’s planned state is not proof that every independently operated client adopted it.

Good reporting follows Lu Heng’s reality-not-advocacy discipline. Describe the query, response and time boundary that exist. Do not promote an intended state into a completed event because the future version is administratively convenient.

Poll position can be lost

The planned-change poll is designed for frequent use. A client normally retains its last ChangeSet ID and asks for everything after it. An empty response then means that the retained ID is the latest change the server currently knows. That is a useful continuity statement, but its scope is narrow.

A new client, or one that lost its last ID, can poll without an ID and receive all ChangeSets the server still knows. The word “still” matters. The draft does not require indefinite retention. It offers examples in which a server might retain old ChangeSets for three months in a busy area or twelve months in a quieter one. A tardy client can fall outside that window.

The system therefore needs an explicit resynchronization state. A client that lost its position must not silently treat the oldest retained ChangeSet as the beginning of history. It should record the gap, obtain a full current validation or another bounded baseline, and establish a new epoch. Otherwise a perfectly ordered stream can produce an incomplete local history.

An empty poll is equally easy to over-read. It does not prove that no unplanned change occurred. It does not prove that an earlier ChangeSet was processed. It does not prove that the local candidate records were replaced. It proves only the relation between the client’s supplied ID and the server’s current list.

This is the difference between a ledger and a throne in Lu Heng’s Policy Mirror. The server’s record should be respected for the function it performs. It should not be made sovereign over facts it did not observe.

Build a two-stage validation receipt

A useful implementation can make preparation auditable without asking the protocol to govern local operations. The record needs two linked but separate observations.

The preparation observation should preserve:

  1. the LoST server and planned-change interface version;
  2. poll time, previous ChangeSet ID and returned ordered IDs;
  3. ChangeSet effective time and exact partial-location selector;
  4. local database snapshot, matching rule, candidate count and exceptions;
  5. location and service supplied for validation, the future asOf time and the server’s answer;
  6. revalidateAfter, cache status, source-document revision and the clock used; and
  7. the planned replacement record, approval state and rollback preparation.

The cutover observation should preserve:

  1. what effective time was actually recognized by the local operator;
  2. when old records were deactivated and replacements became active;
  3. a contemporaneous validation result and any difference from the preparatory answer;
  4. the current LoST lookup used when a service is actually needed;
  5. failed, postponed, superseded and manually handled records;
  6. rollback or exception state; and
  7. the accountable system or person that closed the change.

“Two-stage validation receipt” is an editorial term used here, not a requirement in the draft. It need not be public in full. Location databases can contain sensitive operational data. A public view may expose aggregate counts, time windows, ChangeSet references, completion state and unresolved exceptions, while a protected view retains record-level evidence. A digest can bind the two views, though no digest proves that the underlying decision was correct.

The important design choice is that preparation never overwrites observation. If Friday’s answer differs from Monday’s, both should remain visible. The difference is not merely an error count; it is the history of how institutional knowledge changed.

Revalidation advice allocates cost

The interval between checks is not housekeeping. It allocates the risk of stale data and the cost of querying. The draft notes that a stable, fully built-out area might justify a period of six months or longer, while a fast-growing area might justify 20 to 30 days. These are illustrative judgments, not universal service levels.

A server has an incentive to avoid unnecessary load. A client has an incentive to avoid stale records. A public-safety operator may have a stricter tolerance for ambiguity than another LoST consumer. An organization running many records can prefer targeted ChangeSets; a smaller client may find periodic full validation affordable. revalidateAfter allows the server to advise without taking over the client’s risk decision.

The receipt should therefore record who accepted the final interval and why. It should distinguish server advice from a local override, emergency revalidation from ordinary scheduling, and NO-EXPIRATION from a promise of permanence. If a client lengthens the interval to reduce cost, that is a local decision. If it shortens the interval so aggressively that polling or validation burdens the server, that also has an accountable owner.

The draft’s security section notes that excessive polling can impair other LoST processing. Availability and freshness are joined by capacity. An interval policy that ignores either side can make the other untrue.

What the evidence can and cannot say

A complete preparation receipt can prove that one client obtained a particular planned-change record from one server, matched it against a defined database snapshot and received a stated future validation answer at a stated time. It can show that a replacement was ready before the announced effective point.

A complete cutover receipt can show what the client later activated, what contemporaneous validation returned and whether exceptions remained. Even together, the records do not prove that every possible LoST server held identical data, that a civic authority’s underlying legal act was valid, that a service mapping remained unchanged afterward, or that an emergency communication reached a responder.

Those are not reasons to abandon the record. They are reasons to label each claim by the observation that supports it. Civic authority changes a boundary. A LoST server represents location and service data within its role. A client selects and activates local records. A contemporaneous query returns a current mapping. A communications system attempts delivery. Each verb has a different witness.

The draft’s strength is that it does not collapse those verbs. It permits advance preparation while requiring future answers to remain revisable. Governance should preserve that modesty all the way into dashboards, audits and public claims.

Sources