Summary

  • RFC 2079 defined a case-sensitive, multi-valued labeledURI attribute and an auxiliary labeledURIObject class that could add URI values to an existing X.500 or LDAP entry.
  • An unencoded space separated the URI from an optional human label, but multiple values could mean different related resources or different locations for one resource. The format supplied no relationship type.
  • A stored URI was not a receipt for reachability, freshness, authority or equivalence. A label was not trusted markup: RFC 2079 explicitly warned against inserting it blindly into HTML.

In January 1997, the difficult part of putting a web address in a directory was not drawing a clickable link. Independent groups were already experimenting with URLs in LDAP and X.500. The harder problem was giving those experiments one attribute name and one value form that different clients could recognise.

RFC 2079 called the attribute labeledURI. It was case-sensitive and could appear more than once on the same entry. Each value began with a URI—at that time, a URL under RFC 1738—and could continue with spaces and a friendly label. Because a literal space was not permitted inside the URL, the first unencoded space marked a clean boundary. A client did not need to guess where the address ended and the display phrase began.

That was a genuine coordination achievement. It was also a narrow one.

Multiplicity preserved a question

The memo says that several values would generally identify different resources related to the X.500 object, but might instead identify different locations for the same resource. Those are operationally different claims. A staff profile might link to a home page and a photograph. A service entry might list a primary site and a mirror. A publication might have an HTML view and an FTP copy. Yet the attribute carried no machine-readable word for portrait, mirror, canonical, archive or fallback.

The label could hint at kind or size, but RFC 2079 defined no grammar for it. “Current service” remained prose supplied by a writer, not a verified relation. The directory could prove that a value was attached to an entry under a known attribute. It could not prove why the writer attached it, whether the target agreed, or whether two values were substitutes.

This distinction becomes sharper when strings differ. RFC 3986 later described URI comparison as a ladder. Exact character equality is enough to conclude equivalence, but different strings may still identify the same resource after syntax- or scheme-specific normalization. A case-exact directory value therefore preserves what was written; it does not settle every question of identity.

The object class widened availability, not authority

RFC 2079 also defined labeledURIObject, an auxiliary class derived from top. It required nothing and permitted labeledURI. Administrators could add the class to an existing object rather than redesigning that object's main class. Other classes could include the attribute directly.

Later documents showed both paths. RFC 2798 made labeledURI optional in inetOrgPerson and illustrated a personal home page. RFC 3383 listed the attribute and auxiliary class in LDAP's descriptors table. These records made the definition reusable and discoverable. They did not check the page behind any value, measure adoption, or turn a personal label into organizational endorsement.

RFC 3296 later borrowed the same value form for LDAP subordinate references, but imposed a particular use. Its ref attribute ignored the label, removed it when constructing a referral, used every URI from a multi-valued attribute, and advised the holding server not to validate referential integrity. That narrower protocol shows why the general form was not itself a complete relation: another document had to say what the values did.

Friendly text was an execution boundary

The label was meant for human consumption. RFC 2079 discouraged non-ASCII characters because clients of the period might handle them inconsistently, and it distinguished X.500 character conventions from HTML escapes. More importantly, its security section warned that a program should not paste the label blindly into HTML. A malicious label could contain tags that misled viewers of the surrounding document.

That warning separates storage from rendering. The directory may return the exact label. The client still owns escaping, layout, link destination disclosure and the decision to make anything clickable. The target then introduces another boundary: redirects, content changes, expired hosts and scheme behavior occur outside the stored entry.

The safe evidence chain is therefore longer than the value. First establish the directory entry and attribute value. Parse URI and label. Record multiplicity without guessing its meaning. Identify who supplied the value and what relation they claim. Retrieve the target under an appropriate policy. Then establish provenance, currentness, equivalence and safe presentation separately.

One attribute replaced two names, not two meanings

An earlier draft had defined labeledURL. RFC 2079 deprecated it because the working group preferred one URI attribute to separate URI and URL attributes. It kept the older definition for clients that needed a transition path.

Consolidation reduced the number of attribute names. It did not erase deployed legacy values, prove that migration occurred, or add a relation vocabulary. Nor did the broader word URI make every scheme interchangeable. The cost of a smaller shared surface was that applications still had to preserve the distinctions they actually needed.

RFC 2079's durable lesson is modest and exact. Standardizing how a pointer is attached makes exchange possible. It does not standardize why the pointer matters, whether it still works, or what trust a person should place in the words beside it.

Sources