Summary

  • RFC 1485 gave a known X.500 Distinguished Name a string form suitable for paper and email. Its punctuation preserved an ordered sequence of Relative Distinguished Names rather than replacing the underlying ASN.1 object.
  • “Unambiguous” worked in one direction: a conforming string could reconstruct one DN. Commas or semicolons, layout, type descriptors, quoting and fallback encodings meant that the DN did not have to possess one canonical text.
  • Parsing established structure, not directory state or authority. Entry existence, equality, current attributes, authentication, authorization and external effect required separate evidence.

The comma on the business card

Suppose a conference delegate hands over a card carrying a directory name. One organisation prints its components on a single line with commas. Another lays the same components down a page with semicolons. A third prints an attribute’s dotted object identifier because the recipient’s software does not know its short label. All three cards may preserve the same Distinguished Name.

The historical problem was not how to search for a person from an approximate phrase. RFC 1484 owned that neighboring problem: it took a purported, user-friendly name and searched a directory for candidate DNs. RFC 1485 began later. The DN was already known. The task was to carry its structure through a medium that did not carry ASN.1.

X.500 directory protocols had a formal representation for the name that keyed an entry. Business cards and ordinary mail messages did not. RFC 1485 therefore proposed a user-oriented string notation that could display common cases cleanly yet represent any DN. This sounds like formatting work. In practice, it was a boundary protocol between a structured object and a human surface.

That boundary is where apparently small marks acquire contractual force.

Punctuation had to carry a tree path

A DN is built from Relative Distinguished Names along a path in the Directory Information Tree. RFC 1485 presented those RDNs in a “little-endian” order convenient for people: the more specific portion appeared before broader naming contexts. Within each assertion, = separated the attribute type from its value. A comma or semicolon could separate RDNs. A plus sign joined two or more AttributeTypeAndValue assertions belonging to the same multi-valued RDN.

Those marks were not visual decoration. Moving a plus sign into a comma position would change the structure: two assertions in one naming step would become two successive steps. Dropping a type label would also violate RFC 1485’s DN form, even though the grammar was designed alongside the friendlier conventions explored in RFC 1484.

The notation consequently preserved several distinct facts: which values were asserted, which attribute type belonged to each value, which assertions shared an RDN, and in what order the RDNs formed the name. A parser could recover that structure without asking the reader to infer it from typography.

But the RFC also allowed different layouts. A semicolon and line break could make a long name more attractive. A comma could keep it compact. The same structural facts therefore did not imply the same visible line.

The ugly form carried the strongest promise

Readable names were the easy test. Generality appeared at the edges.

Values containing separator characters, quotation marks, leading or trailing spaces, or consecutive spaces needed quoting and escaping so that display characters would not be mistaken for grammar. An unfamiliar attribute type could be written as a dotted numeric object identifier. When an attribute value lacked a suitable string display, RFC 1485 allowed the encoded value to appear as hexadecimal BER.

The memo called that last result ugly and expected it mostly for pathological cases. Yet the ugly form did the deepest engineering work. Without it, the notation would have described only the values its authors found pleasant to print. With it, the notation could claim to carry any DN, including a future or private attribute unknown to the receiving interface.

This is an early example of a durable Internet design pattern: keep the ordinary path legible, but reserve a lossless escape route for facts that the current vocabulary cannot name elegantly. The fallback should not be confused with universal understanding. A parser may reconstruct an OID and encoded value while the application still has no schema, display rule or operational meaning for it.

One parse did not require one spelling

“Unambiguous” is easily over-read. RFC 1485 sought a string that could be parsed back into an unambiguous DN. It did not need to prove that every DN had one authorized textual spelling.

Its permitted separators and layouts already created multiple presentations. Attribute types might later be expressed by a registered descriptor or by a numeric OID. Values could cross the string boundary through escaped text or an encoded form. A serializer’s registry, encoding policy and formatting choice all influenced the bytes a reader saw.

The later lineage made the distinction more explicit. RFC 1779 replaced RFC 1485. RFC 2253 brought an LDAPv3 UTF-8 representation, and RFC 4514 replaced it. RFC 4514 expressly declines to define a canonical DN string and permits alternative conversion algorithms so long as their output can be parsed. It directs equality decisions to distinguishedNameMatch, not raw text comparison.

This retrospective clarification helps interpret the older achievement precisely. A conforming string could be determinate as input to a parser while the serializer remained free to choose among more than one valid surface. Parseability is not canonicality.

A matching decision required more than eyesight

Two copied strings may differ yet denote DNs that compare equal. Two strings that look alike may contain different code points, encodings or structures. A screenshot records glyphs. A mail archive records bytes. A parser records a reconstructed sequence of RDNs. A directory matcher applies schema-selected rules to attribute values. These are connected witnesses, not interchangeable proof.

RFC 4512 locates DN structure and equality in the directory information model: attribute types have syntaxes and matching rules, and a DN refers unambiguously to an entry in the tree. RFC 4517 specifies syntaxes and matching rules used by LDAP. RFC 4518 adds preparation for internationalized string matching, including mapping, normalization and handling prohibited characters.

That separation matters when reconstructing history or operating legacy systems. Lowercasing a copied DN, trimming spaces, replacing an OID with a remembered label or comparing Unicode display text byte-for-byte may create false matches or false differences. The safe record retains the original bytes, character-set assumptions, serializer and parser versions, descriptor registry, parsed structure, schema and equality rule.

The name still stopped before the directory

RFC 1309 described the distributed X.500 environment in which Directory User Agents contacted Directory System Agents, while chaining, referrals, naming contexts and replicas distributed custody of directory information. RFC 1485 did not repeat that architecture. Its output was a representation of the DN that could be supplied to a directory operation.

Successful parsing therefore proved something narrow: the receiver had reconstructed a structured name. It did not prove that an entry with that name existed in the consulted directory at that time. It did not reveal whether a replica was stale, access controls hid attributes, an entry had moved, or the schema used the expected matching rule.

Even a successful lookup stayed short of human identity. The entry represented an object under the directory model. The DN did not authenticate the person, establish control of a service, confer a role, authorize a payment or prove delivery of a message. Those conclusions belonged to identity providers, application owners and external institutions, each with its own receipt.

RFC 1485’s security section said security issues were not discussed. A modern reader should not retrofit confidentiality, integrity, spoof resistance or authorization into punctuation that was designed to preserve name structure.

Historic does not mean inert

The RFC Editor record now marks RFC 1485 Historic. RFC 3494 was part of the action that retired the LDAPv2 technical specification. Later DN-string RFCs improved character encoding, escaping, descriptor handling and the explanation of equality.

Obsolescence is a lineage fact, not an eraser. It neither proves that old strings vanished from mail archives and configuration files nor that every implementation migrated them identically. It also does not make the original problem trivial. Every generation that moves a structured identifier through a human text surface must choose how to preserve unknown values, how to version parsers and how to distinguish display stability from semantic equality.

The RFC’s value is clearest when its claim is kept small. It supplied a reversible boundary for a known name. It did not centralize the directory, choose the object behind the entry or settle the action a relying system would take.

A receipt chain for names

Heng Lu’s accounts of running-code primacy, localized future decision and reality layers offer a useful way to read this boundary. A shared minimum notation made exchange possible. Local serializers could choose presentation. Parsers reconstructed structure. Directory operators retained current state. Matchers, authenticators and applications made later decisions in their own domains.

The disciplined evidence chain is correspondingly plural: original structured DN, serialized bytes, transport treatment, parse result, schema-aware equality decision, directory snapshot, entry version, authentication, authorization and outcome. Collapsing that sequence into “the name proves it” gives typography powers the protocol never assigned to it.

RFC 1485 made a difficult name portable. Its lasting lesson is that portability becomes trustworthy only when every boundary keeps its own receipt.

Sources