Resumen

  • Derivar una cuenta del nombre humano facilita predecirla, pero comprime identidades distintas en un espacio donde las colisiones crecen con el número de pares posibles.
  • RFC 1439 recomendó mostrar siempre el sufijo que desambigua, rechazar la forma sin sufijo y no reasignar el identificador mientras persistan referencias de correo.
  • Nombre visible, usuario, identificador estable, buzón, aceptación SMTP, credencial y autorización son capas de prueba diferentes, aunque una interfaz las presente como una sola “identidad”.

El directorio no tenía sitio para dos cadenas iguales

Una organización podía enseñar una convención sencilla: combinar nombre, inicial y apellido, y usar el resultado como cuenta. Esa regla tenía una ventaja social. Cualquier corresponsal que conociera un ejemplo podía inferir muchas direcciones sin pedir ayuda.

La segunda persona que producía el mismo resultado rompía la ilusión. La cadena no había identificado a un ser humano; solo había propuesto una clave. A partir de ahí alguien debía decidir si añadía un número, si mayúsculas o signos creaban diferencias, si la primera persona conservaba la versión más elegante y si una baja liberaba la cadena. La autoridad de esas decisiones pertenecía al sistema que operaba el espacio de nombres.

RFC 1439, publicada por Craig Finseth en marzo de 1993, era informativa y no una norma de Internet. Organizó el problema en tres métodos. El primero emitía identificadores opacos y únicos sin datos de la persona. El segundo derivaba la mayor parte del nombre y ajustaba la cadena hasta hacerla única. El tercero también partía del nombre, pero resolvía duplicados de manera ad hoc.

El correo electrónico generalizado favorecía las opciones predecibles. Sin embargo, predecir una cadena no equivale a demostrar su vínculo. El nombre es un dato de presentación. La normalización produce una forma de comparación. La consulta de disponibilidad observa un estado local. La asignación crea una relación técnica. Cada verbo tiene un sujeto y un instante distintos.

La colisión llega antes de llenar el espacio

El documento calculó la información típica y máxima de iniciales, nombres y combinaciones. La mayoría de formatos habituales quedaba entre 8 y 20 bits típicos; la combinación típica más rica alcanzaba 26 bits y ningún máximo listado superaba 40. La conclusión era que los duplicados podían aparecer con poblaciones modestas.

La explicación fue el problema de los cumpleaños. El riesgo depende de cuántos pares pueden coincidir, no solo del porcentaje visible de claves ocupadas. Para el formato de nombre y apellido, estimado en 17 bits típicos, RFC 1439 calculó entre 2 % y 5 % de probabilidad —aproximadamente 4 %— en una organización de 100 personas. Con 1.000, la probabilidad era muy superior al 20 %.

No conviene universalizar esas cifras. Los repertorios usados en 1993, las culturas de nombres, los alfabetos, la transliteración y la población de cada institución cambian la distribución. La enseñanza general es otra: la longitud gráfica no mide la diversidad efectiva. Quitar tildes, plegar mayúsculas, eliminar espacios, truncar o romanizar puede juntar entradas que antes eran distintas.

Por eso la palabra «único» está incompleta sin tres datos: ¿único dónde?, ¿comparado cómo?, ¿durante cuánto tiempo? La estética de la cadena no responde ninguna de esas preguntas.

Rechazar la dirección ambigua protege al remitente

El apéndice analizó el patrón First.M.Last-#. ¿Podía la primera persona usar la forma sin número y recibir la segunda un -2? La respuesta fue negativa. Si la forma desnuda entrega al primer titular, el remitente no obtiene ninguna advertencia de que quizá quería al segundo. Si todos llevan número y la forma incompleta se rechaza, el error obliga a obtener el discriminador correcto.

Aquí el rechazo no es una avería. Es una salida honesta cuando el sistema carece de información para elegir. Resolver en silencio a favor del primer registro convierte la incertidumbre en un éxito falso.

La RFC relacionó este argumento con el cuidado del correo y mencionó la Electronic Communications Privacy Act estadounidense de 1987. Esa mención describe el razonamiento histórico del autor, no el derecho vigente. La conclusión técnica no necesita ampliarla: entregar a un buzón válido no prueba que sea el buzón de la persona que el remitente imaginaba.

El texto aconsejó además no reutilizar esos identificadores durante la vida del sistema de correo. Una reasignación es una colisión entre tiempos. Agendas, mensajes archivados, listas, permisos, flujos de recuperación y memoria humana pueden seguir apuntando al ocupante anterior. La nueva persona hereda no solo la cadena, sino también la confianza y las acciones pendientes asociadas a ella.

El protocolo entrega responsabilidad, no identidad

RFC 5321 diferencia la dirección, una cadena que identifica a un usuario o un lugar de depósito, del buzón que actúa como depósito. Solo el host indicado por el dominio asigna semántica a la parte local. Desde fuera, la misma forma puede representar a una persona, una cola, un alias, un programa o un archivo operativo.

Cuando el servidor devuelve éxito al final de los datos, SMTP transfiere formalmente la responsabilidad: el servidor debe entregar o informar bien el fallo. Esa señal prueba un relevo dentro del protocolo. No demuestra lectura humana, titularidad de la persona esperada ni resultado de un proceso posterior.

RFC 2142 muestra que algunas direcciones se diseñaron expresamente para no ser personas. postmaster, abuse, noc y security nombran servicios, roles y funciones. El dominio debe dirigir el mensaje a un destinatario apropiado para el rol. El titular humano puede cambiar sin que cambie la dirección.

Tampoco la igualdad de cadenas es universal. SMTP exige conservar las mayúsculas y minúsculas de la parte local y formalmente permite que sean significativas, aunque desaconseja explotarlas porque perjudica la interoperabilidad. El dominio no distingue caso. Un intermediario que normaliza todo por intuición puede alterar la clave que la autoridad de destino pretendía interpretar.

Un esquema necesita más de una clase de identificador

RFC 7643 separó en SCIM cuatro superficies. id lo emite el proveedor, es único dentro de sus recursos, estable y no reasignable. externalId lo emite el cliente de aprovisionamiento y queda limitado a su dominio; el servidor no impone su unicidad. userName es visible para el usuario y único entre los usuarios del proveedor. Los campos del nombre humano se guardan aparte.

La separación revela quién puede afirmar qué. El proveedor gobierna su clave estable y su espacio de usuarios. El cliente gobierna su referencia externa. Los datos de presentación describen, pero no reemplazan esos vínculos.

RFC 8265 añade los usuarios internacionalizados. Define el nombre de usuario como designador de una cuenta, utilizada a menudo pero no necesariamente por una persona, y recomienda separar identificadores restrictivos de nombres visibles más expresivos. Ofrece un perfil que transforma mayúsculas y otro que las conserva. La aplicación o el despliegue elige; la transformación pierde información y debe aplicarse en un punto declarado.

Así aparece una escalera de evidencia. El nombre visible presenta. La normalización propone. La disponibilidad observa. La asignación vincula una casilla. La dirección dirige hacia el dominio. SMTP transfiere responsabilidad. La autenticación verifica control de una credencial. La autorización permite una acción. Una respuesta humana por un canal independiente puede añadir evidencia, pero tampoco convierte el usuario en identidad universal.

El diseño mínimo no tiene que legislar cómo se presentan todos los nombres. Debe fijar lo que otros sistemas necesitan para interoperar: alcance, comparación, colisión, asignación y no reutilización. El registro describe el vínculo; el código que compara y enruta produce la realidad operativa.

Fuentes