Summary

  • RFC 1484 let people enter a short, untyped and approximate User Friendly Name, but called that input a purported name: the directory still had to resolve it to one or more Distinguished Names.
  • The result depended on an ordered local environment, current directory entries, schema, alternate values, matching behavior and sometimes a human choice. The same characters could therefore produce a different candidate set elsewhere or later.
  • A resolved DN identified a directory entry. It did not by itself authenticate the person, authorize an action, validate every attribute or prove an external outcome.

The same spoken name entered two different machines

Imagine a visitor in 1993 saying “Andrew Findlay, Brunel.” At one terminal, the directory client begins within a British environment and tries national organisations before broader possibilities. At another, a public client begins from a different country or locality. The visitor has not changed the words. The machines have not been given the same search program.

RFC 1484 was an unusually candid attempt to make this useful. X.500 Distinguished Names could locate entries in a hierarchy, but their typed form was awkward to exchange on a business card or type from memory. The memo proposed a User Friendly Name, or UFN, that could resemble the way one person described another at a meeting.

Its important noun was not “name” but “purported.” The string supplied by the user was a purported name. It was expected to resolve to a DN; it was not the DN itself. The design made names easier by permitting the user to omit information that software could recover through schema assumptions and directory search.

That bargain put context back into the act of identification. The sentence typed at the keyboard was only one input. The directory around it supplied the rest.

Friendliness came from leaving things out

RFC 1484 allowed several kinds of omission. Attribute types could disappear, so Sofia Ren, Example Institute, GB did not need to spell out Common Name, Organisation and Country. Higher components could be abbreviated relative to a local environment. An intermediate organisational unit could be left out. Alternate values and approximate spellings could stand in for registered values. A friendly country name could replace a two-letter code.

These features did not merely shorten an existing stable key. Some were resolved by default schema; others required search. The memo gave an organisational hierarchy as a default, but allowed context-dependent and data-dependent variants. An untyped two-letter component under one country might be treated as a state. An omitted locality might be found by exploring more than one attribute type.

The user experience became pleasantly direct: type what another human said and let the client do the form filling. The evidence experience became more demanding. To reproduce a result, an investigator needed the typed input, parser and locale rules, assumed schema, abbreviation base, search filters, directory contents and candidate-selection path.

The visible string no longer contained everything that made it resolve.

The local environment was executable context

Every RFC 1484 match occurred in a local environment. The environment was an ordered list of non-leaf names in the Directory Information Tree. It could vary with the number of components supplied and was meant to be controllable by the individual user.

The example for a private directory user started a one-component search inside a department, then the university, then the country, then the root. A two-component name began elsewhere. A public United States client used a different ordering. This was not decorative personalization. Order determined which directory subtree was searched first and whether a match stopped further exploration.

Suppose two organisations both contained a convincing “J. Martin.” A client rooted inside one organisation could return its local entry as a good match before attempting the other. A public client might present both. Adding a new exact alternate value could outrank yesterday’s approximate candidate. Moving a department in the tree could change the path by which a short name was understood.

The algorithm therefore had a time dimension. RFC 1484 advised systems to store a DN in most cases, specifically warning that a purported name could become ambiguous when a new name appeared. A friendly name that was unique at a conference was not promised permanent uniqueness in a growing directory.

Exact, good and poor were decisions, not adjectives

The proposed resolver classified matches as exact, good or poor. An exact DN match was followed. Good matches were followed when no exact match existed. Poor substring or approximate matches were shown to the user. Multiple branches could remain alive until later components removed the ambiguity.

The labels sound qualitative, but they controlled a state machine. Whether punctuation was ignored, an initial matched a full given name, a short token triggered substring search, or an alternate value counted as good depended on implementation and data. The user’s rejection could force the client to continue with the next environment element. A prompt was part of the resolution, not an error outside it.

That makes a screenshot reading “found” incomplete evidence. One needs to know which candidates existed, how they were ranked, which were suppressed by limits or access controls, what the user accepted, and whether later search branches completed. A candidate entry is not yet a selected entry; a selected entry is not yet an authenticated person.

RFC 4511 later made the LDAP search receipt more explicit. A search has a base object, scope, alias policy, size and time limits, filter and requested attributes. It can return entries and continuation references before a final result. A single plausible entry observed on screen does not prove that the search space was complete.

A DN solved a narrower problem

The directory substrate mattered. RFC 1309 explained that an X.500 entry occupied a place in a Directory Information Tree and that its Distinguished Name was assembled from Relative Distinguished Names along the path. The published RFC 1309 Article owns that distributed architecture, including aliases, DUA and DSA roles, chaining, referrals and replica custody. RFC 1484 asked a different question: how could a human guess a path without typing all of it?

Its companion, RFC 1485, specified a string representation for a DN already known. RFC 1779 later replaced that syntax; RFC 2253 carried DN strings into LDAPv3 with UTF-8; and RFC 4514 defines the current LDAP representation.

Those documents expose three separate objects. A UFN is input to a lookup. A DN is the structured name of an entry. A DN string is a serialization of that structure. RFC 4514 adds a useful warning: it does not define one canonical string representation. DN equality uses a directory matching rule, not raw string equality. Two textual forms may encode names that compare equal; two strings that look similar may not.

RFC 4512 locates that decision in the schema. Attribute types supply syntaxes and matching rules, RDNs must be unique among siblings, and a DN unambiguously refers to an entry in the tree. RFC 4518 shows how internationalized strings are prepared for matching. Glyphs, bytes, normalized values and directory equality are not interchangeable witnesses.

An entry was not the person standing in front of the terminal

Resolution could succeed perfectly and still leave larger questions open. A DN identified a directory entry. The entry was a named collection of information representing an object under the directory model. It could contain alternate values, contact details or application endpoints. None of that made the lookup an authentication ceremony.

The client still needed a record of which server answered, which directory state it observed, which access controls hid attributes, whether referrals were followed and which candidate the user chose. A relying application needed its own authentication and authorization evidence. A real-world institution retained authority over employment, role or legal identity. A message sent after lookup needed a delivery receipt.

This is the limit of the word “identity.” RFC 1484 tried to help one human name an entry another human had in mind. It did not turn ease of recall into proof of control.

The experiment reported both delight and debt

The memo reported an implementation in the FRED interface of the PSI Pilot and in a prototype distribution-list tool. User reaction was described as favourable. That was meaningful implementation evidence, and the document published example sessions rather than pretending the algorithm existed only on paper.

It also recorded where the experience broke down. The algorithm handled multiple levels of organisational unit poorly when the user guessed a unit not immediately below the organisation. Leading and trailing wildcard searches might be inefficient in directory implementations. Ambiguity, actual use, performance and algorithm variants still needed investigation.

The RFC Editor record preserves the document’s place in the record. It does not turn favourable reactions into a population study or prove continued deployment. RFC 1484 was Experimental, and its security section said security issues were not discussed. A later reader must not manufacture privacy, resistance to enumeration or identity assurance from a usability proposal.

The historical achievement was an honest split

RFC 1484 did not fail because it needed context. Its achievement was to admit where context lived. It separated the human expression from the directory key and supplied an inspectable procedure between them.

That split fits Heng Lu’s accounts of running-code primacy, localized future decision and reality layers. The shared notation was small. The local client retained environment and matching choices. The running directory supplied current facts. The user made a bounded selection. The relying system made a later decision.

A friendly name could begin the chain. The honest record kept the rest: utterance, parsed purported name, environment, directory snapshot, filters, candidates, chosen DN, entry version, authentication, authorization and outcome. Ease belonged at the interface. Authority belonged to the receipts that followed.

Sources