Summary

  • RFC 3017 made a roaming phone book machine-readable enough to select a point of presence and configure dialing, DNS, proxies, gateways and usernames, but it explicitly did not define the update or transfer protocol.
  • Its monotonically increasing book and entry counters could signal difference inside a known scope. They did not prove who issued the data, which audience variant applied, whether a client committed it, or whether the listed access service still worked.

The traveler had two files. One said version 41. The other said version 73. If the problem were only arithmetic, the choice was obvious.

But the files did not necessarily describe the same book. A roaming consortium could prepare different versions for different groups of users. A customer could then extract a country-specific or wireless-only subset. The book name was an arbitrary string, and the standard supplied no global publisher identity inside that name. Seventy-three was higher than forty-one; it was not automatically newer for this person, this journey or this configuration lineage.

That distinction sits at the center of RFC 3017, published in December 2000 as XML DTD for Roaming Access Phone Book. The document standardized more than a list of telephone numbers. Its XML could tell software which network point of presence to select and how to configure the host after selection. It could carry media type, minimum and maximum rate, tunnel protocols, a dialing script, pricing information, DNS and mail servers, web and FTP proxies, a default gateway, support contacts, and strings to add before or after a username.

This was a control bundle wearing the familiar name “phone book.”

The consortium compiled a view, not a universal reality

The information path began with network providers. Members supplied descriptions of their services and access servers to a roaming consortium. The consortium assembled those contributions into a unified book for customers. RFC 3017 expected differentiation: groups could receive books adapted to their needs, and users could derive further subsets.

That architecture enabled portability. It also created provenance boundaries. A POP entry might begin as an operator statement, pass through a consortium compilation, appear in an audience-specific edition, and then survive in a user's extracted subset. Each step could preserve XML validity while changing completeness, ordering, surrounding references or update lineage.

RFC 2194 had already documented the operational background. In one reviewed roaming system, members sent provider and POP information to a secretariat, which manually compiled available numbers and published updates through FTP, web and client mechanisms. The phone book could include locations, proxies, dialer configuration, support contacts and server settings. That history does not prove RFC 3017 deployment. It does show why a shared format mattered: multiple organizations were already turning distributed claims into configuration consumed by travelers.

The DTD solved one part of that problem. It gave all parties a common grammar. It did not make every edition the same view of the world.

A counter described change only after its scope was known

At the top level, phoneBook@version was a monotonically increasing integer that should advance whenever the book changed. A server could compare the client's number with its current number and decide that some action was needed. The RFC offered an example: the server might return a URL for a file containing differences.

The text did not define that difference file. It did not define the request, transport, authentication exchange, atomic commit, rollback or recovery process. Indeed, the introduction expressly excluded any phone-book update or transfer protocol.

The number therefore had narrow meaning. It could answer, “Does the server believe this named book differs from the client's book?” It could not, by itself, answer:

  • Which issuer owns the counter namespace?
  • Is this the full book or an audience-specific edition?
  • Was a locally derived subset renumbered?
  • Which base does a proposed difference file expect?
  • Did the client receive every byte?
  • Did validation finish before the old book was replaced?
  • Was the new configuration activated?
  • Did a newer edit correct a stale POP or merely alter branding text?

A larger integer was not a time source. It was not a signature. It was not a commit receipt.

RFC 2477 makes the separation unusually clear. Its criteria for a phone-book update protocol required server authenticity, movement from an arbitrary previous version to the latest version, integrity checking before an update was applied, verification of the resulting book, lightweight transfer, and selection of language and character set. Those requirements existed precisely because a format counter could not perform them.

The entry counter had no complete merge contract around it

Each pop carried an entryVersion, also described as monotonically increasing and potentially useful in merging or updating books. Yet the POP element itself did not have an XML ID. Setup, support and provider containers did have IDs and could be referenced within the document; a point of presence was described through its address, media and other content.

This matters when state changes shape. A counter can say that a recognized object changed, but the surrounding system still needs to know which object is being recognized. If a telephone address changes, is the result a modified POP, a replacement POP or two POPs? If an entry disappears, is it intentionally deleted, excluded from this audience's subset, temporarily absent from a partial transfer or lost during compilation? RFC 3017 did not define tombstones or conflict rules. It never claimed to.

That was an update-protocol problem, outside the DTD. The operational error would be to infer a complete merge algorithm from the presence of entryVersion.

The same restraint applies to extensibility. The RFC separated an extensible set of parameter-entity declarations from a fixed structural part and proposed IANA registration policies. New information elements had to be optional so older documents would remain valid. Preserving the validity of an old document, however, does not prove that an old dialer understands the meaning of every new value in a new document. Compatibility needed a parser, a supported extension set and a local policy for unknown or unusable data.

Validation checked shape, not the network behind the text

XML DTDs did not provide strong typing for the operational values in the book. Much of the content was #PCDATA. RFC 3017 added notations for intended types such as FQDN, IP address and encoded images, but a notation did not query a DNS server, dial a modem, verify a tariff or establish that a gateway was reachable.

A document could be perfectly well formed and still contain a retired phone number. It could validate while a listed proxy refused the traveler. It could name a tunnel protocol that the local implementation lacked. A minimum rate could describe a capability rather than the rate observed on that call. Pricing text could be syntactically present and commercially out of date.

The gap became more consequential because clients could act on the fields. The dialScript element held the script for connecting to a POP. Setup could provide DNS, mail and proxy servers or a default gateway. An intelligent dialer could automatically concatenate username prefixes and suffixes. A stale entry was therefore not only a misleading label. It could direct a call, alter an identity string and route subsequent application traffic.

The phrase “phone book” made the artifact sound descriptive. Its behavior could be executable.

A signature protected a claim, not its continued truth

RFC 3017's security section required reliable authentication of the issuer and integrity protection for distributed phone-book information. It placed those functions outside the DTD and suggested signing the book with PGP as one possible mechanism.

That division was correct. XML validity and issuer authentication are separate tests. But the tests should not be recombined into a stronger conclusion than either can support.

An external signature can establish that the verified bytes are the bytes authenticated under a particular key and signature policy. It does not call every number in the book. It does not ask the operator whether a POP was withdrawn after signing. It does not prove that the signed edition was intended for this customer group. It does not show that the client committed the file without mixing it with an older base.

Nor does authentication of the update server prove the later access session. RFC 2486 placed the Network Access Identifier in the PPP authentication path and used its realm-like form to help route an authentication request. That occurred after selection and dialing. A correct POP number could lead to a NAS that rejected the identity. A successful physical link could still fail authorization. A successful login could still receive unusable addressing, DNS, proxy or tunnel state.

The evidence chain had multiple receipts because the operation had multiple stages.

Configuration could arrive from more than one authority

The Setup element described values that might differ by provider or POP. RFC 3017 also acknowledged that some could be available by another means, such as DHCP.

That created a practical question the DTD did not answer: if the phone book says one DNS server and DHCP supplies another, which is authoritative? The answer could depend on the client, provider, access method, security policy and time. The format could represent one claim, while a running network supplied another.

This is not evidence that the design was defective. It is evidence that configuration ownership lives outside a serialization grammar. Operators needed to record which layer produced each value, which one won, and what the host actually used.

A failure ticket reading “book version 73 installed” would be too coarse. The useful record would include the issuer and book name, audience variant, full digest, selected POP and entry version, signature result, parser and extension set, download base, commit result, active configuration digest, dial outcome, PPP state, authentication result, address assignment, tunnel state, DNS and proxy observations, and application reachability.

Only then could an investigator distinguish a stale entry from a bad merge, a failed dial, a rejected identity or a service outage.

The history is a lesson in bounded standardization

RFC 3017 did not pretend that one DTD could operate the entire roaming system. It standardized the part that needed a portable common shape and named the surrounding responsibilities it did not standardize. That restraint is more valuable than a retrospective complaint that the document lacked a modern update framework.

The mistake would come later, in an implementation or audit, if a narrow artifact were treated as a universal proof.

Lu Heng's Running-Code Primacy provides one useful lens: published configuration has to meet the network before it becomes operational fact. His Reality Layers lens keeps document shape, authenticated issuer, installed state and successful service from collapsing into one label. Minimum Initial Specification explains why a common format can remain thin, but also why transition rules, compatibility labels, local validation and observable adoption still need explicit homes.

These are analytical lenses, not claims about the authors' motives.

The traveler needed the phone book. Without a portable list, roaming across many providers was brittle and manual. But the number printed at the top could never bear the whole burden of freshness.

It said the book had changed. The network still had to answer.

Sources