Summary

  • RFC 3404 defined URI resolution as a typed request. I2L, I2R, I2C and I2N asked for locations, resource instances, descriptions and persistent names; singular and plural forms also carried cardinality.
  • S, A and U described the representation used for the next DDDS step. P did something categorically different: it left DDDS for application-specific processing. Discovery still did not authenticate the resolver or the returned resource.

The dangerous word in a resolver log is often not an error code. It is “success.” A system can successfully answer a question that its caller never asked. If an application wants a description of a work and receives one place from which a copy might be downloaded, the lookup has not merely varied in format. Its meaning has changed.

RFC 3404, published on the Standards Track in October 2002, confronted that distinction inside Dynamic Delegation Discovery System applications for URI and URN resolution. It belonged to a five-document DDDS series. RFC 3401 introduced the family, RFC 3402 defined the algorithm, RFC 3403 mapped rules into DNS NAPTR records, RFC 3404 defined the resolution applications, and RFC 3405 assigned the uri.arpa. and urn.arpa. trees.

The architecture began with an Application Unique String. For generic URI resolution, the absolute URI was canonicalized and encoded into the form expected by the application; its scheme supplied the First Well Known Key. The DNS key appended that scheme to uri.arpa.. URN resolution used the Namespace Identifier and urn.arpa. instead. In both cases NAPTR rules could rewrite or delegate until processing reached a terminal result or another system.

The two applications were technically identical enough that one specification described both. They were operationally separate for a strategic reason. URN resolution already had a shortcut model and should not have been made dependent on adoption of a universal URI resolver. Separating the well-known keys let a namespace deploy useful resolution without waiting for every URI scheme to join the same system.

The Services field carried the missing semantic type. I2L meant URI-to-location and returned one location URI; I2Ls permitted one or more. I2R and I2Rs returned instances of the resource. I2C returned a description, and I2N returned a URN. The final case came with an important warning: comparing two URNs for equality could be nontrivial. The apparent simplicity of the returned string did not remove namespace-specific rules.

These were not synonyms for “give me anything relevant.” A location is a statement about where a resource might be obtained. A resource instance is the thing delivered through the resolution protocol. A description is metadata about it. A name aims to preserve identity independently of current location. The same identifier might support all four operations, but evidence for one did not satisfy another.

Cardinality also belonged to the contract. The lower-case s in I2Ls and I2Rs meant that a response could contain multiple results. A consumer that silently chose the first item converted a set-valued answer into a singular one and assumed the selection policy. A receipt therefore needed to record the requested service, the response class, every returned result and the consumer's eventual choice.

RFC 3404 allowed an optional protocol prefix before the resolution services. Yet a protocol name was not a URI-resolution contract. The specification demanded separate definitions of how a request encoded the desired service and how the response represented it. Saying “HTTP” identified a protocol family; it did not say whether an operation requested a location, content or metadata, what status and media type meant, or how multiple values were serialized.

That requirement exposed a boundary still useful today. Service discovery can find a capable endpoint. It cannot manufacture an application protocol from a transport label. Interoperability requires the request and response semantics that connect the advertised capability to an observable result.

The Flags field described another dimension. S, A and U were DDDS terminal flags. S said that the rule output was a domain name for an SRV query. A led to address records for a domain name. U produced a URI. They were called terminal because the DDDS loop stopped; a later resolver or protocol could still have substantial work to do.

P looked like a peer letter but was not a DDDS terminal flag. It declared that the remainder of processing was application-specific and no longer followed DDDS concepts. That is a control-boundary statement, not merely another output encoding. Calling P terminal inside DDDS would hide the fact that a different ruleset had taken authority.

The four flags were mutually exclusive in the 2002 application, but the RFC warned implementers not to assume the field would forever have length zero or one. Later applications could define combinations. Unknown flags had to cause the record to be ignored and processing to continue. This check came before normal ordering because an unknown flag could alter how every later field should be interpreted.

An empty Services string was also valid. Early in a delegation chain, the rule publisher might not yet know which protocol and service the eventual resolver supported. Empty did not mean malformed or semantically universal. It meant that this rule delegated before the final service capability was determined.

RFC 3404 offered one carefully bounded optimization. Within records sharing the same ORDER, a client could search for a more applicable service instead of blindly following the first preference. But the chosen record still had to preserve the basic DDDS algorithm's input and output. The search could not cross delegation paths, inspect a higher ORDER after a match, or turn a deterministic delegation into an unconstrained catalogue query.

The distinction matters because “better service” is a client judgment, while ORDER encodes published authority. Confusing them lets local capability override the administrator's delegation structure. A client may prefer one protocol among equivalent options; it may not treat an easier endpoint in another authority layer as equivalent.

Additional SRV or address records could accompany an answer and reduce round trips. They were an optimization only. The application had to work when a nameserver omitted them. A verifier must distinguish “the resolver discovered the next name” from “the client also received convenient glue” and from “the downstream connection succeeded.”

Security divided along the same seams. Locating a resolver did not define how to communicate with it securely. That responsibility belonged to each resolution protocol. DNS administration of uri.arpa. and urn.arpa. introduced availability, spoofing and delegation risks. A validated DNS path still did not authenticate an application response, prove the resource was the intended one or establish that a description was current.

Regular expressions added a local execution risk. Implementations were expected to sanity-check expressions rather than pass them blindly to environments with dangerous capabilities. A signed or correctly delegated rule could remain unsafe to execute. Authenticity and safe interpretation were separate evidence.

The RFC Editor currently lists three editorial errata. Verified errata 282 and 787 correct references that point to RFC 3404's own “Additional Information” processing when they should point to RFC 3403. Erratum 2923, held for document update, corrects reference numbers in Section 4. None changes the flag model, the typed resolution services or their cardinality.

A useful operational receipt for RFC 3404 therefore preserves the canonical input, scheme or namespace, first key, DNS query, complete NAPTR set, known-flag decision, protocol, requested resolution service, cardinality, same-ORDER selection, chosen rule, S/A/U/P handoff, next query or URI, resolver request encoding, authenticated peer, response content type, returned object class and consumer outcome.

Lu Heng's Minimum Initial Specification principle clarifies why the document standardized these narrow boundaries rather than one universal resolver. Shared labels were useful only when their outputs were precisely typed; protocol details could remain local and evolve. Running-Code Primacy then supplies the test: ask the same identifier for a location, a resource and a description; remove Additional data; introduce an unknown flag; vary same-ORDER capabilities; and confirm that the implementation changes only where the contract permits.

RFC 3404 did not promise that every identifier could yield every answer. It made implementations say which answer they sought and which handoff they followed. That discipline turned “resolution succeeded” from a reassuring but empty status into a claim that could be inspected.

Sources