Resumen

  • RFC 3383 distribuyó los identificadores LDAP entre Standards Action, revisión experta, Specification Required, orden de llegada, experimentación y uso privado según el daño potencial de una colisión.
  • Registrar un valor demostraba coordinación, no implementación ni seguridad. La evidencia útil era el vínculo público con una especificación, un responsable y una vía de cambio.

Una colisión de identificadores puede parecer un mensaje válido. Dos implementaciones reciben el mismo entero y cada una lo interpreta como un resultado distinto. No hay necesariamente un error de codificación que active una alarma. El protocolo sigue hablando, pero ya no comparte significado.

RFC 3383 apareció en septiembre de 2002 como BCP 64 para gobernar ese límite. LDAP admitía nuevas operaciones, extensiones y esquemas. La cuestión no era si podía crecer, sino cómo asignar nombres a ese crecimiento sin convertir el espacio común en una colección de acuerdos privados incompatibles.

El documento evitó una aprobación única. Los tipos de mensaje, mecanismos descubribles, códigos de resultado, métodos de autenticación, descriptores de OID y opciones de atributos tenían efectos diferentes. La política debía reflejar esa diferencia.

Una especificación de la IETF podía recibir un arco OID de Internet Directory Numbers mediante Expert Review con Specification Required. IANA asignaba un arco por especificación. Después, el propio texto podía distribuir OID subordinados sin volver a coordinar cada hoja. El registro garantizaba la rama y la especificación administraba su interior.

Quienes trabajaban fuera de la IETF podían usar OID debidamente delegados, incluidos los de Private Enterprise Numbers. Los prototipos debían preferir el arco experimental para que el código temprano no quedara atado a los valores definitivos. Los OID experimentales no debían sobrevivir en una especificación publicada.

Los controles y extensiones anunciados en Root DSE tenían otra ruta. Los mecanismos descubribles podían registrarse por First Come First Served con Specification Required. Si pertenecían al Standards Track, necesitaban Standards Action. El acceso relativamente ligero exigía una descripción pública, pero no fingía que esa descripción fuera un estándar.

La diferencia entre políticas es sustantiva. El orden de llegada no evalúa calidad técnica. Una especificación disponible no prueba adopción. La acción de estándares no certifica una implementación. Cada fórmula define qué coordinación debe preceder a la ocupación de un espacio concreto.

Los descriptores ofrecían nombres breves para OID. No distinguían mayúsculas y podían existir varios nombres para un OID. Un nombre acabado en guion reservaba una familia. x- quedaba para uso privado y no se registraba; e- identificaba experimentos por orden de llegada; los demás nombres requerían revisión experta.

Las opciones de AttributeDescription usaban una partición semejante. El prefijo informaba sobre el alcance de la promesa. Un valor privado podía ser útil dentro de una organización, pero no adquiría unicidad mundial ni documentación pública por llevar x-.

Los resultCode dividían el campo numérico. De 0 a 1023 se exigía Standards Action; de 1024 a 4095, Expert Review con Specification Required; de 4096 a 16383, First Come First Served y palabra e-; desde 16384, y para palabras x-, Private Use no registrable.

Los métodos de autenticación repetían esos intervalos y añadían COMMON, LIMITED USE u OBSOLETE. Sin una especificación pública no podían ser COMMON, y una inscripción nueva no podía comenzar como OBSOLETE. El registro capturaba la intención de uso, no una medición de su difusión real.

Un tipo nuevo de mensaje LDAP requería Standards Action. Los mensajes extensibles reducían la necesidad de tocar la elección principal de la envoltura, pero no la eliminaban. Por eso el núcleo del protocolo tenía una barrera mayor que un experimento local.

El RFC también cerró el registro de Directory Systems Names, heredado de LDAPv2, porque LDAPv3 usaba descriptores de OID con otra sintaxis. La lista existente debía seguir pública por razones históricas. Dejar de asignar no autorizaba borrar el pasado.

Las reglas adquirían fuerza mediante el procedimiento. La revisión experta exigía publicar un formulario completo durante dos semanas. Una modificación reiniciaba el periodo. Cualquier participante podía objetar; el experto aprobaba y remitía o denegaba, y la decisión podía apelarse. First Come First Served enviaba el formulario directamente a IANA.

El modelo también asignaba propiedad. IESG controlaba los valores de Standards Action; los solicitantes controlaban normalmente los de revisión experta y orden de llegada. Una actualización debía satisfacer restricciones equivalentes a una alta nueva. Si el propietario no podía o no quería reparar un registro, IESG podía asumirlo.

Las objeciones de terceros podían adjuntarse como comentarios tras revisión experta cuando no había acuerdo con el propietario. Esa posibilidad reconocía que un registro público no siempre elimina la disputa. Puede, al menos, conservarla junto al valor para que los futuros implementadores no hereden una falsa unanimidad.

Las plantillas pedían identificador, descripción, especificación, contacto, autor o controlador de cambios, uso y comentarios. Ese conjunto convertía un número en memoria operativa. Sin él, nadie sabría qué contrato leer ni quién podría corregir una interpretación obsoleta.

RFC 2434 proporcionó el vocabulario general y RFC 8126 lo actualizó más tarde. Las páginas actuales de parámetros LDAP de IANA demuestran continuidad del registro, no que su presentación permanezca idéntica a 2002 ni que todos los valores tengan software activo.

RFC 3377 situó el documento en el LDAPv3 de la época. RFC 2251, RFC 2252 y RFC 2255 aportaron el contexto de protocolo, esquema y URL; RFC 4510 describió después la especificación revisada. Es una secuencia documental, no un censo de despliegue.

La idea duradera fue variar la fricción. Una norma completa para todo ensayo habría bloqueado la experimentación. Una asignación indiscriminada habría hecho barata la entrada y costosas todas las colisiones posteriores. Las zonas experimentales y privadas ofrecían escape sin prometer coordinación universal.

La especificación inicial mínima de Lu Heng permite ver la economía del diseño: fijar particiones, políticas, plantillas, propietarios y reparación, dejando cada extensión futura en su documento local. Sus capas de realidad separan asignación, registro, especificación, implementación, despliegue y resultado. Confundirlas convierte una fila registral en una certificación que nunca fue.

RFC 3383 hizo de la extensibilidad una tarea de custodia. El identificador daba un lugar. La política determinaba el coste de entrar en lo común. El registro mantenía localizables el significado, el responsable y el camino de corrección cuando la asignación ya era historia.

Fuentes