Summary

  • RFC 3383 did not place every LDAP extension behind one approval gate. It matched Standards Action, Expert Review, Specification Required, First Come First Served, experimental and Private Use space to different interoperability risks.
  • A registered identifier was coordination evidence, not proof that an extension was implemented, secure or interoperable. Its value came from the public specification, steward, review path and change-control history attached to it.

Two developers can both make LDAP extensible and still make their products unable to talk. If each assigns the same result-code integer to a different outcome, the wire value remains perfectly decodable while its meaning splits in two. The danger is not that the protocol lacks room. It is that shared room can be occupied twice.

RFC 3383, published in September 2002 as Best Current Practice 64, treated this as a governance problem with technical consequences. LDAP already supported new operations, extensions to existing operations and extensible schema. The document asked how the identifiers for those additions should enter common use without turning flexibility into collision.

Its answer was not a single registry queue. Different namespaces received different policies. LDAP message types, result codes, authentication methods, protocol mechanisms, Object Identifier descriptors and AttributeDescription options did not carry identical risks. RFC 3383 therefore assigned different amounts of friction to each.

For IETF-developed elements, a specification could request one Object Identifier under the Internet Directory Numbers arc. Assignment required Expert Review with Specification Required. Once the arc was assigned, the specification could allocate as many subordinate OIDs as it needed without returning to IANA for each leaf. The registry coordinated the branch; the defining document governed the local tree beneath it.

Other developers could use any properly delegated OID, including one below an Internet Private Enterprise Number. Work in progress was encouraged to use the experimental OID arc so early implementations would not collide with the identifiers later chosen for the published specification. Experimental OIDs were not to appear in published specifications. The temporary lane was useful precisely because it was not the destination.

Discoverable protocol mechanisms received another balance. LDAP Root DSE attributes could advertise supported controls and extensions through OIDs. Those discoverable mechanisms generally used First Come First Served with Specification Required, making a public technical description available without requiring a full standards action. A Standards Track mechanism, however, had to be registered through Standards Action.

The distinction is easy to flatten and important not to. First Come First Served did not certify technical quality. Specification Required did not mean IETF standardization. Standards Action did not prove deployment. Each policy answered a narrower question about what evidence and review had to exist before a value occupied a particular shared space.

Descriptors introduced a human-readable layer over numeric OIDs. They were case-insensitive short names, and more than one name could refer to one OID. A descriptor ending in a hyphen could reserve a whole family of names. Values beginning x- belonged to Private Use and could not be registered. Values beginning e- were reserved for experiments and used First Come First Served. Other descriptors required Expert Review.

AttributeDescription options followed a similar partition, with their own length guidance and registration policy. Again, x- marked Private Use and e- an experimental lane. Other options needed Standards Action or Expert Review with Specification Required. The prefixes were not decoration. They declared that a name lived under a different coordination promise.

The numeric spaces made the risk allocation even more visible. For result codes, values from 0 through 1023 required Standards Action. Values from 1024 through 4095 required Expert Review with Specification Required. Values from 4096 through 16383 used First Come First Served and paired with experimental e- keywords. Values 16384 and above, together with x- keywords, were Private Use and not registrable.

Authentication methods used the same numeric partitions, while adding a use classification: COMMON, LIMITED USE or OBSOLETE. A method without a publicly available specification could not be classified COMMON. A new registration could not enter directly as OBSOLETE. The registry therefore recorded more than a number; it recorded an assertion about intended scope, with evidence conditions around that assertion.

LDAP message types received the strictest simple rule: new values required Standards Action. LDAP already had extensible message mechanisms, which reduced but did not eliminate the need for new top-level types. Changing the envelope's basic choice space carried a different coordination cost from naming a private experiment.

RFC 3383 also knew when to close a registry. Directory Systems Names had served the LDAPv2 string representation of distinguished names. LDAPv3 used OID descriptors with a different syntax. New Directory Systems Names were no longer accepted, but the existing list was to remain publicly available for historical purposes. Closure did not require erasure.

The registration process made policy operational. Standards Action requests travelled through IESG approval. Expert Review requests were posted using a completed template for two weeks of public review. If the requester revised the form, the review period restarted. Anyone on the list could object. The appointed expert approved and forwarded the request or denied it, and the action could be appealed.

First Come First Served requests went directly to IANA with the completed form. Ownership also differed: IESG was treated as owner of Standards Action values; requesters owned Expert Review and First Come First Served registrations. That owner was not merely a historical credit. It mattered when the entry needed maintenance.

An owner could update a registration under the same constraints and review as a new one. If an owner could not or would not make a necessary update, IESG could assert ownership to repair the record. Significant objections from others could be attached as comments after Expert Review when the owner did not agree to change the registration. Coordination included a memory of disagreement, not just a final cell in a table.

The templates in the RFC reveal what the registry was meant to preserve: identifier, description, specification, contact, author or change controller, usage and comments. A bare number could prevent two clean allocations from being identical, but it could not explain what the value meant, who could correct it or where an implementer should find the technical contract.

RFC 2434 supplied the general registration-policy vocabulary that RFC 3383 applied to LDAP. RFC 8126 later updated that general guidance and terminology. The current IANA LDAP Parameters pages show that the registries remain a living public surface. They should not be read as proof that every field or procedure is unchanged from 2002, nor that every listed mechanism has an active implementation.

RFC 3377 located RFC 3383 alongside the LDAPv3 technical specification of its period. RFC 2251, RFC 2252 and RFC 2255 supplied the protocol, schema and URL extension contexts referenced by the registry rules. RFC 4510 later described the revised LDAP technical specification. These links establish chronology and dependency, not an adoption census.

The durable design idea is differentiated friction. A space whose collisions would fracture core messages demanded Standards Action. A space useful for publicly specified extensions could use expert review or simple allocation. Experiments and private deployments retained escape valves, but their prefixes and ranges warned others not to treat them as globally coordinated public meaning.

That arrangement avoided two opposite failures. Requiring full standardization for every experiment would push innovation outside the process or freeze it. Allowing every shared value to be claimed without documentation would make extension cheap at the moment of allocation and expensive at every later interoperability failure. RFC 3383 placed the cost where the risk lived.

Lu Heng's minimum-initial-specification lens clarifies the architecture. The document did not attempt to decide every future LDAP extension. It defined the smallest governance substrate through which future decisions could remain local: partitions, policies, templates, owners and repair paths. The initial specification made change possible without pretending that change had no coordination cost.

His reality-layers lens adds a necessary restraint. Allocation, registration, specification, implementation, deployment, successful negotiation and user-visible outcome are separate layers. A registry entry is strong evidence at the coordination layer. It is not evidence that software shipped, that a security review succeeded or that two implementations behaved the same.

RFC 3383's historical contribution was to make extensibility legible as stewardship. The identifier gave an extension a place. The policy decided what it had to disclose before entering shared space. The registry kept the meaning, owner and route for correction discoverable after the allocation moment had passed.

Sources