Summary

  • RFC 1959 encoded an LDAP server location, distinguished name, requested attributes, scope and filter into a portable URL; omitted attributes, scope and filter invoked defined defaults rather than recording observed facts.
  • An omitted host left server selection outside the string, and the format offered no place for credentials. The same URL could therefore be resolved through different server, session and access-control contexts.
  • A URL described how to construct a search. It did not prove which server was contacted, which attributes policy allowed, whether the result completed successfully or what a relying application later did.

A directory instruction learned to travel

The useful achievement of RFC 1959 was compression without prose. An Internet client did not need a paragraph telling it to contact a directory server, begin at a particular distinguished name, request certain attributes and search at a specified depth. Those choices could be placed in a URL and passed through systems that already knew how to carry URLs.

The memo arrived at a particular moment. LDAP was described as a lightweight front end to X.500, but the authors deliberately made the format broad enough for stand-alone LDAP servers. A directory operation was becoming a web-addressable object even though the directory itself retained its own protocol, namespace and policy.

That distinction matters. The URL was not a copy of the directory entry. It was not a certificate about an entry. It was not even the complete LDAP protocol request. It was a compact instruction from which a client could construct a search.

RFC 1959's grammar placed the fields in a fixed order: ldap://, an optional host and port, a slash and distinguished name, then optional question-delimited fields for attributes, scope and filter. The punctuation was small, but it separated different decisions. A host located a server. A distinguished name selected the search base. An attribute list described what the client wanted returned. Scope chose the base object, one level or a subtree. A filter selected which entries would match.

The existing history of RFC 1558 belongs one layer inside that final field: it explains how a readable LDAP Filter remained an executable predicate. RFC 1959's different contribution was to carry that predicate together with the rest of the search envelope. The outer URL did not absorb the filter's grammar, and the filter did not determine the server, base, attributes or scope.

Empty fields still made choices

The shortest examples reveal more than the fully populated form. RFC 1959 said that omitting the port meant TCP port 389. Omitting the attributes meant that all attributes of the entry or entries should be returned. Omitting scope meant a base-object search. Omitting the filter meant (objectClass=*).

Those were construction defaults. They were not evidence collected from the directory. A missing attribute field did not report that every attribute existed. A default presence filter did not assert that an entry was authentic, current or permitted to the caller. A base scope did not prove that the named object existed. The default completed an instruction; the server still had to evaluate it.

The University of Michigan subtree example made absence visible with two adjacent question marks: ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen). The blank attributes position allowed the following sub scope and filter to keep their places. Nothing had been forgotten accidentally. The empty field deliberately delegated one part of the request to the default.

That is an important historical design lesson. Optional syntax does not create an undefined void. It transfers control either to a specified default or to another actor. An audit that stores only the visible non-empty values can miss the decisions produced by absence.

RFC 1959 also relied on two layers of representation. The distinguished name followed the directory's string rules, with verified erratum 528 correcting a mistaken grammar reference from RFC 1485 to RFC 1779. Characters illegal in a URL, such as spaces, were then escaped using RFC 1738 percent encoding. The filter similarly kept its own LDAP syntax inside the URL encoding.

Percent encoding made the string transportable. It did not make a DN canonical, a filter safe, or a decoded value authoritative. A client first had to recover the inner text and then apply the inner grammar. The bytes carried across the URL boundary and the directory object later selected remained separate evidence.

Three slashes left an operator outside the string

The most consequential omission came before the path. A URL such as ldap:///o=University%20of%20Michigan,c=US named no host. RFC 1959 said that, if the entry belonged to the X.500 namespace, the URL could be resolved by contacting any LDAP server that provided X.500 back-end access.

This was useful portability. A reference did not have to be tied to one server name. It was also an explicit evidence gap: the URL alone did not say which server the client selected, whether that server was reachable, what copy or view it exposed, or when the query ran.

“Any” did not mean “all”, and it did not mean “authoritative”. It described a permitted route to resolution under the memo's X.500 assumption. A stand-alone LDAP server did not automatically become interchangeable with every other server. A modern reader should not turn the 1996 sentence into a universal discovery rule that the document never supplied.

RFC 2255, which replaced RFC 1959 in 1997, made this division clearer. If no server was named, the client needed prior knowledge of an appropriate one. The client could open a new connection or reuse an existing connection. It could choose security services, authenticate under its own policy and fill SearchRequest fields that the URL did not specify, including size limit, time limit and alias dereferencing.

Those later clarifications illuminate the original boundary without retroactively adding fields to RFC 1959. The 1996 URL did not encode a server-selection algorithm, connection history, time limit, size limit, alias policy or transport protection. A faithful historical account must preserve the difference between what the early format carried and what later processing specifications explained.

No credential travelled with the reference

RFC 1959's security section is only a few lines, but it sets a hard limit. The format had no way to specify credentials, so requests were expected to be unauthenticated. Resolving the URL had the same security implications as resolving any LDAP query.

An unauthenticated query is not an unauthorized query by definition. A directory may intentionally publish data to an anonymous client. Nor is it an entitlement to receive everything named by the request. The directory's access rules determine what the current session may see.

This is where the phrase “all attributes should be returned” needs discipline. In the URL grammar, omission the attributes field means that the client requests the broad default. It does not compel the server to disclose values hidden by access control or other administrative restrictions. Later LDAP protocol text makes the separation explicit: matching entries and their attributes remain subject to access control, and a returned entry can contain no attribute values.

The absence of a credential field also prevents a copied URL from serving as identity proof. Two people can hold the same string and resolve it in different sessions. One may receive public attributes, another a restricted view, and a third an error. The differences are not contradictions in the URL. They are facts about the server, session, policy and time of execution.

RFC 2255 later introduced an extension mechanism and discussed authentication policy; RFC 4516 eventually removed the old bindname extension for lack of known implementations while retaining extensive warnings about automatic URL processing and security. The evolution is evidence that the boundary required operational care, not evidence that RFC 1959 secretly carried credentials.

Search instructions did not freeze the result

An LDAP search can produce zero or more entries and references before a final result. Modern RFC 4511 describes a SearchResultDone message that reports success or error after the preceding result messages. RFC 1959 did not compress that sequence into the URL, and it did not turn the URL into a snapshot.

The distinction becomes practical when a URL is cited as evidence. The string can show the intended base, scope, filter and requested attributes. It cannot show that the server evaluated the same data at a later time. It cannot show that a size or time limit did not truncate work, that references were followed, that access policy stayed constant, or that a final success result arrived.

Even a returned entry is not the whole receipt. It shows what one server emitted to one client at one point in a result sequence. It does not alone establish completeness, uniqueness, freshness or authority beyond the server's own context. A relying program must decide whether one result is enough, whether absence is meaningful, whether a referral should be followed, and whether any later action is safe.

The URL specification did not make those decisions. A browser might display contact information. A configuration tool might prefill a field. A directory client might invite another search. None of those actions follows automatically from the string. Each adds a new policy and consequence surface.

The later standard preserved the narrow lesson

RFC 4516 now defines the LDAP URL for LDAPv3. It adds clearer percent-encoding rules and an extension mechanism, and it explicitly notes that not every parameter of an LDAP SearchRequest can be expressed in the format. LDAP URLs may also carry reference knowledge, including for operations other than searches.

That broader use does not erase the original accounting. A URL remains a representation consumed by a client. The client chooses how to process it within security policy, constructs protocol operations, receives bounded responses and hands information to another layer. Portability connects those steps; it does not merge their authority.

Heng Lu's minimum-initial-specification principle provides a useful editorial lens. RFC 1959 was valuable because its common surface was small enough to carry. The mistake would be to let that convenience accumulate powers it did not define: server discovery, identity, permission, completeness and application intent.

The running-code principle supplies the corresponding evidence test. The document proves that a URL format was specified. A captured string proves that one representation existed. A client trace can prove how it parsed defaults. A connection record can prove which server and security context were used. LDAP messages can prove a result sequence. An application log can prove a later act. No earlier record should impersonate the later one.

The reality-layer distinction keeps the claim modest. RFC 1959 made a query portable. It did not make the query sovereign.

Sources and limits

RFC identity, status and document history are recorded by the IETF Datatracker and RFC Editor information page. The original wording is available in RFC 1959 HTML and plain text; verified erratum 528 corrects the DN reference. The protocol, filter and URL syntax context comes from RFC 1777, RFC 1558 and RFC 1738. The resolution and successor boundaries are in RFC 2255, RFC 4511 and RFC 4516.

The analytical frame comes from Heng Lu's Running-Code Primacy, Minimum Initial Specification and Reality Layers. Those essays guide the separation of representation, execution and authority; they are not evidence of an LDAP deployment.

These sources establish the specifications and their stated boundaries. They do not establish present deployment share, product conformance, a named directory, a real query result, a breach, a current access policy or any dependent application's decision.