Summary

  • RFC 3402 defined a recursive discovery algorithm in which each nonterminal rule produced the key for another database lookup, yet every substitution continued to operate on the exact Application Unique String supplied at the start.
  • That invariant separated delegated authority from subject identity. A chain could change where it looked without accumulating transformations that silently changed what it was resolving.

The easiest way to misunderstand a rewrite system is to imagine a sentence being edited from left to right. One rule transforms it, a second receives the new text, and a third works on the second result. By the end, the output may be useful, but the path has become a game of telephone: every intermediary can redefine the object inherited by the next.

RFC 3402 prohibited precisely that model. Published on the Standards Track in October 2002 as Part Two of the Dynamic Delegation Discovery System, it described an algorithm for lazy binding. An application began with an Application Unique String, or AUS. It then discovered rules as needed, traversed delegated databases and stopped when a terminal rule produced the application's expected result.

The historical importance lies in what moved and what did not. A nonterminal substitution result became the key used to retrieve the next ordered set of rules. The result did not become a new AUS. When the next rule was tested, its substitution expression was applied once again to the original string. RFC 3402 stated the requirement in normative language and repeated it in the obligations placed on application specifications.

The first step was deliberately different. A First Well Known Rule, defined by the application rather than fetched from the rule database, converted the AUS into the first valid database key. That rule anchored discovery in an application contract. It prevented a client from beginning with an arbitrary database merely because that database happened to accept a convenient string.

A lookup then returned an ordered rule set. The client tried substitution expressions in order against the original AUS until one produced a non-empty result. A rule also carried Services, Flags and Priority. These were not ornamental fields: they told the application whether the rule offered an acceptable service, whether the result was terminal, and how to prefer otherwise equivalent choices.

Service rejection did not mean the whole process had failed. If a matching rule described a service the client could not or would not use, the client resumed within the same retrieved list after that rule. This detail preserved order and evidence. A client could not quietly restart at the top and pretend the rejected alternative had never been considered, nor could it jump to an unrelated database without declaring another transition.

If the accepted rule was nonterminal, its substitution output had one role: the next database key. The application validated that key against the database's syntax and performed another lookup. At the next stage, the newly obtained rules still matched the original AUS. The key selected the authority to consult; it did not acquire the identity of the subject.

RFC 3402 called the forbidden alternative fragile and error-prone, invoking sendmail-style rewrite chains as the caution. In a cumulative chain, an unexpected intermediate output changes the material available to every later rule. Diagnosis then requires reconstructing mutable state at each hop. Under the DDDS invariant, every rule can be tested against one stable input, and every intermediate output can be judged only as a routing key or terminal result.

There was a defined boundary rather than an absolute ban on delegation to other systems. An application's Flags could suspend processing and hand control to another DDDS Application or a protocol-specific rule system. RFC 3404's protocol-specific p flag was the example. But that was an explicit change of algorithmic context. The original application's rules did not continue while secretly operating on a replacement subject.

Terminal rules closed the loop. Their outputs had to satisfy the application's expected-output contract and were returned with the rule's Flags and Services. A terminal string was therefore not self-authenticating. It showed that the algorithm reached an endpoint under a declared application and database; it did not by itself prove that the downstream service was available, that the database authority was legitimate, or that a consumer accepted the result.

Priority had an equally narrow meaning. It expressed preference among otherwise equivalent rules, such as a faster, cheaper or better alternative. RFC 3402 explicitly said it was not a load-balancing mechanism. Distribution of traffic belonged elsewhere, for example in SRV where the selected application used it. Reading Priority as a traffic weight would turn a deterministic preference signal into behavior the standard did not promise.

Freshness constrained optimization. A client might remember prior keys or rules to avoid repeating work, but it had to respect the database's expiration semantics. If a previously used rule had expired, the application returned to step one. It could not splice a fresh suffix onto a stale prefix and still claim to have executed the same delegation path.

This division of duties was broader than the algorithm itself. An Application specification had to define the AUS, the First Well Known Rule, permitted Databases, character-set treatment and terminal output. A Database specification had to define storage, lookup, key and rule formats, insertion rules and collision avoidance. RFC 3401 warned that reading only one part of the series invited misunderstanding because compliance existed in the combination.

The abstraction also admitted what it could not decide. DDDS could derive a delegation result from the AUS and rules. It could not natively decide conditions requiring outside knowledge, such as time of day, payment, rights or other transactional facts. Smuggling those facts into an unexplained rule result would make the observable chain appear more authoritative than it was.

Security followed the same logic. RFC 3402 could identify dynamic delegation points as attack surfaces, but it could not enumerate concrete protections without a particular Application and Database. DNS NAPTR records in RFC 3403, URI Resolution in RFC 3404 and the earlier ENUM work in RFC 2916 each supplied different semantics. They illustrated the algorithm; none licensed the conclusion that every DDDS implementation understood every application.

The IANA ENUM Service Registrations registry is contemporary evidence of coordinated identifiers in one later DDDS application. Registration proves that a label is assigned, not that a resolver executed it, that a rule was fresh, that an authority was entitled to publish it, or that a terminal service succeeded. The RFC Editor currently lists one verified editorial erratum for RFC 3402, Errata ID 7049, correcting the section number of RFC 3404's p-flag discussion from 4.4 to 4.3. The correction does not change the invariant.

An operational receipt for DDDS therefore needs more than the final string. It should preserve the original AUS, application and version, First Well Known Rule, database type, every lookup key, each returned ordered rule set, record identity and freshness, substitution match and output, service rejection and resume position, priority decision, terminal flag, expected-output validation and final consumer outcome.

Lu Heng's Minimum Initial Specification principle explains the architecture's restraint. The RFC standardized the minimum boundary independent implementations had to share, while leaving application meaning and database mechanics to their own specifications. Running-Code Primacy adds the proof discipline: replay the original AUS through captured fresh rules, verify each key and resume point, and show that no implementation ever substituted an intermediate key for the subject.

RFC 3402 did not merely organize a sequence of regular expressions. It preserved identity across delegation. Authorities could decide where the next question should be asked, but each one had to answer for the same starting object. The chain was allowed to move. Its subject was not.

Sources