Summary

  • RFC 2377 proposed DNS-derived dc components and familiar uid values to avoid building another global name registry, but explicitly warned that an email-shaped UID might not be a valid mailbox; applications had to inspect the separate mail attribute.
  • The mailbox domain and directory path did not have to match, equal DNs could exist on independently managed servers, and a DN did not locate or authenticate an LDAP service. Familiar syntax coordinated names without proving contact, identity, authority or outcome.

The cheapest registry was one that already existed

By 1998 the X.500 directory model had supplied hierarchy, delegation and distributed lookup, yet its conventional naming practice remained difficult to deploy. Organisations needed registered names inside country and regional branches. Legal names could be long, unfamiliar or contested. Common names collided as soon as many people named John Smith shared one branch.

RFC 2377 answered by reusing Internet naming infrastructure. A registered domain such as acme.com could become dc=acme,dc=com, the root of an organisation's directory subtree. Leaves could use uid when an existing identifier store was available, or cn for objects created specifically for the directory.

The proposal was Informational and voluntary. Its ambition was not to declare one mandatory world directory. It was to remove a costly commissioning step: do not build a second global registry when DNS names, employee handles and mailbox identifiers already supplied collision-resistant material within known administrative scopes.

A familiar string received a narrower job

For a person, the memo suggested a “distinguished” RFC 822 mailbox identifier as a convenient UID. The result looked reassuringly operational: uid=mailbox-shaped-identifier,dc=acme,dc=com. A user might recognise it, and an administrator might already have a unique value on file.

But RFC 2377 then drew the line that matters. Some populations used email-like aliases as identifiers for everyone even when a few people had no working mailbox. The string remained useful for distinguishing entries. It did not thereby become a deliverable address. Directory applications were told not to assume that uid was a mailbox and to check the mail attribute instead.

The distinction is more than pedantry. A UID answers which entry is being named within a directory context. A mail attribute makes a contact assertion. SMTP execution supplies later evidence about routing and delivery. Authentication binds a session to a principal. None of these receipts can be manufactured from the presence of an at-sign.

The two domain paths could disagree on purpose

The memo also refused to make the UID's domain control directory placement. The domain part of external-mailbox-shaped-identifier could sit inside dc=mis,dc=acme,dc=com. The dc path might organise access control or partition directory information, while the selected identifier preserved a person's external or historically stable handle.

That freedom prevented a directory reorganisation from forcing an email-address change. It also defeated a tempting shortcut. Software could not safely split the UID at at-sign and reconstruct the authoritative DN, nor could it turn the DN back into the person's current mailbox.

RFC 2377 did require the concatenated dc components to form a registered DNS name. That reused DNS delegation to avoid hierarchy collisions. Registration established naming scope, not equivalence among the domain registrant, a directory service, an LDAP endpoint, an organisation entry and every person below it.

A DN did not choose one server

The companion RFC 2247 defined a reversible mapping between a DNS name and a DN made entirely of dc components. It explicitly did not define how to locate an enterprise's LDAP server from the domain. Its security section warned that an untrusted server could claim naming contexts for domains never delegated to it.

RFC 2377 imagined loosely coupled server “islands”. Referrals could connect servers that shared a DN namespace. LDAP URLs could cross islands by combining a host, port and DN. The host was therefore evidence absent from the DN itself.

The authors did not expect one global DIT to survive competing service providers. Independently managed servers could hold different directory objects with the same DN for the same real-world subject. A directory object was a set of attributes, and the application made the association with a real-world object. The plan did not erase the possible one-to-many relationship.

Naming, finding and seeing remained different

Even when uid named a person entry, cn remained required by person-derived object classes and useful for searches. The attribute chosen to prevent RDN collisions was not automatically the best display label or discovery key. A stable handle, a familiar name and a contact route served different functions.

The plan also exposed a privacy trade-off. Access controls might block browsing in parts of the Directory Information Tree, yet public DNS names could still reveal clues about protected structure. Reusing an observable registry reduced naming friction while importing information about organisational boundaries.

RFC 4519 later made the definitions of uid, dc, dcObject and uidObject definitive for LDAP. It updated schema text, not the evidentiary rank of the values. A conforming UID still does not prove a mailbox, a human identity, an authenticated server or an authorised action.

Reuse without semantic promotion

Lu Heng's reality-layers discipline clarifies why the design remains useful. DNS delegation, a structured DN, a serialized DN string, a UID, a mail attribute, an LDAP URL, an authenticated response, an access-control result and a delivered message are related records. A system may derive one from another, but the derivation needs its own rule and receipt.

Running-code primacy asks what the deployed directory and mail systems actually returned. Minimum initial specification explains the virtue of RFC 2377: it created a workable starting convention while preserving local choice. The mistake would be to reward that convenience by promoting a borrowed label into evidence it was never designed to carry.