Resumen

  • La RFC 2345 separó la localización de información empresarial de la administración del DNS y de los conflictos sobre derechos en un nombre.
  • El servidor definía qué significaba «nombre de empresa», cómo aceptaba abreviaturas y qué coincidencias consideraba correctas; el protocolo no validaba esas decisiones.
  • Cada línea contenía una URL y una etiqueta libre, sin identidad legal, procedencia, fecha, confianza ni prueba de control del dominio.
  • El prototipo ordenaba por puntuación, limitaba la respuesta a diez resultados y abría automáticamente una única coincidencia, aunque esa unicidad solo perteneciera a una base concreta.
  • La relación con una empresa, el control técnico de la página y la prestación efectiva del servicio exigían comprobaciones distintas.

El buscador respondía a una pregunta más estrecha

A finales de los noventa, una costumbre parecía razonable: si alguien conocía el nombre de una compañía, podía probar ese nombre bajo .com. El crecimiento de la Red hizo visible la fragilidad del supuesto. Había nombres repetidos, jurisdicciones distintas, marcas compartidas y sitios fuera de .com.

La RFC 2345 distinguió tres problemas que solían mezclarse: la política de administración de dominios, los derechos sobre nombres y la localización de información para una entidad conocida por su nombre habitual. Su propuesta se limitó al tercero.

Ese recorte fue importante. Un directorio podía ayudar a encontrar una página sin rediseñar el DNS y sin arbitrar marcas. Pero también fijó el límite de la respuesta. El servicio indicaba un lugar en el que mirar; no resolvía las controversias que había dejado fuera.

WHOIS aportó un sobre, no una autoridad

El experimento reutilizaba la mecánica mínima de WHOIS. Un cliente conectaba con el puerto TCP 43, enviaba una línea y recibía una o varias antes de que el servidor cerrara la conexión. La RFC 954 ya había descrito ese intercambio para información legible por personas.

En la RFC 2345, la entrada era un supuesto nombre de empresa. La salida normal colocaba primero una URL, después espacios y finalmente un nombre visible. El orden permitía separar campos sin un analizador complejo.

La forma común facilitaba clientes pequeños. No obligaba a que los proveedores compartieran datos, fuentes o política editorial. El sobre podía ser idéntico aunque el contenido hubiera sido investigado con rigor, copiado de un registro antiguo o inferido de una página dudosa.

Un nombre cotidiano no identificaba a una persona jurídica

La especificación dejó a cada servidor decidir qué grafías, abreviaturas y variaciones aceptaría. También excluyó de su alcance la corrección de la coincidencia.

Por eso una respuesta válida en términos de protocolo podía enlazar el texto con la entidad equivocada. Dos empresas de países diferentes podían usar el mismo nombre corto. Una filial podía compartir marca con el grupo. La razón social podía haber cambiado. Una transliteración podía ocultar varios originales. Eliminar «S.A.» o «Ltd.» podía ayudar a buscar y, al mismo tiempo, borrar una distinción importante.

La insensibilidad a mayúsculas era una regla técnica. No era resolución de identidad. Ninguna gramática podía sustituir la prueba de jurisdicción, número de registro y relación corporativa.

La etiqueta tampoco tenía semántica certificada

La RFC llamó «company name» al texto que seguía a la URL, pero permitió que contuviera un nombre, una ubicación, un tipo de actividad u otra información elegida por el servidor. Era una etiqueta de selección para la interfaz.

No existían campos obligatorios para el identificador legal, la fuente, el responsable editorial, la fecha de comprobación, la confianza o el historial de cambios. Tampoco había una declaración estándar sobre la relación entre la entidad mostrada y el dominio.

La ausencia de estructura fue deliberada. Los autores querían minimizar la interpretación entre la entrada, la consulta, la respuesta y la acción. Ese objetivo favorecía el despliegue, pero impedía atribuir a la línea un significado que nunca transportó.

La URL señalaba un recurso, no la propiedad

La RFC 1738 definía una URL como representación compacta para localizar y acceder a un recurso. Advertía que una URL podía dejar de apuntar al mismo objeto con el paso del tiempo.

El dominio incluido en una respuesta RFC 2345 podía pertenecer a la compañía nombrada, a su matriz, a un agente, a un proveedor técnico o a un tercero. La página podía ser auténtica y estar delegada. También podía estar desactualizada, redirigida o comprometida. La línea no decía cuál de esas relaciones se aplicaba.

El propio documento contemplaba la suplantación del servidor de traducción: un atacante podría hacer que se devolviera una URL incorrecta. Como defensa, remitía a certificados, firmas y otros indicios de autenticidad. Esos controles adicionales solo tienen sentido porque el mapping no era prueba suficiente.

Además, la RFC 1591 separaba el registro de un dominio de los derechos marcarios. Si ni siquiera el registro otorgaba estatus de marca, una recomendación de directorio no podía demostrar titularidad sobre el nombre.

La coincidencia única era un hecho local

La interfaz propuesta trataba de forma especial una única respuesta. Podía pedir confirmación o abrirla como si el usuario hubiera escrito la dirección. El cliente de demostración elegía la segunda opción: un solo resultado lanzaba el navegador automáticamente.

Pero «uno» describía la salida de una base y unas reglas de búsqueda. No afirmaba que existiera una sola empresa posible. Una variante omitida podía esconder otra ficha. La base podía carecer de una sociedad reciente. La normalización podía unir entidades distintas. Otro proveedor podía devolver varios candidatos.

La interfaz comprimía toda esa incertidumbre en una navegación inmediata. La velocidad era una propiedad del cliente; la certeza no aumentaba con ella.

El límite de diez revelaba la selección

El servidor de demostración documentado tenía aproximadamente 209.000 registros proporcionados por Dun & Bradstreet. Si encontraba diez o más, solo devolvía los diez primeros. La aplicación los mostraba de mayor a menor puntuación.

Esa práctica introducía orden y truncamiento sin que el protocolo definiera el cálculo. El primer resultado no era una autoridad: era el candidato que una función privada había situado arriba. La ausencia de un undécimo elemento en pantalla no demostraba que no existiera.

El mensaje Not found también era acotado. Solo indicaba que la cadena no coincidía con nada en esa base. La compañía podía existir, tener una web o aparecer con otra grafía.

El prototipo no ofrecía altas ni correcciones y rechazaba responsabilidad por la exactitud. Por tanto, una empresa ausente no tenía dentro de ese sistema una vía documentada para reparar el vacío. Esta limitación afectaba directamente a la interpretación de la respuesta negativa.

La calidad se fabricaba fuera del protocolo

La RFC fue explícita: la calidad dependía del directorio y del trabajo editorial y de investigación empleado para construirlo. Esas tareas quedaban fuera del protocolo.

Un servidor podía cumplir cada byte y mantener datos viejos. Otro podía usar las mismas líneas con verificación cuidadosa. Para distinguirlos había que conocer la procedencia, la fecha de vigencia, las fuentes contradictorias, la política de actualización y el mecanismo de rectificación.

La corrección del transporte respondía a «¿qué dijo este servidor?». La corrección informativa exigía responder «¿por qué lo dijo y qué evidencia tenía?». La RFC estandarizaba la primera pregunta y confiaba la segunda al proveedor y a la presión del mercado.

Elegir proveedor era elegir un marco editorial

No se exigía un único servidor ni un registro de proveedores. El cliente debía permitir la selección. La pluralidad podía mejorar cobertura y especialización, pero hacía posible que una misma consulta produjera resultados distintos sin infracción del protocolo.

Por eso una captura de pantalla sin proveedor, fecha, consulta exacta y versión del conjunto de datos perdía parte de su valor. Repetir la consulta en otro servicio no era consultar una réplica neutral; era contrastar otra decisión editorial.

El mercado podía premiar los mejores directorios. No podía certificar retroactivamente cada respuesta concreta.

Llegar al sitio no probaba el resultado del usuario

Incluso si el enlace era oficial, aún quedaban etapas. El DNS debía resolver, la ruta debía funcionar, el certificado debía encajar en el contexto, las redirecciones debían permanecer bajo control aceptable y la página debía ofrecer aquello que el usuario buscaba.

Un sitio oficial podía anunciar un producto suspendido. Un formulario podía cargar y fallar al enviar. El soporte podía no responder. Una transacción exitosa un día no garantizaba continuidad.

La secuencia correcta era: sugerencia del directorio, relación entidad-dominio, control técnico, autenticidad de la página y resultado del servicio. Cada paso necesitaba evidencia propia.