Resumen

  • RFC 3367 definió un núcleo interoperable para consultar servicios de nombres comunes, descubrir sus capacidades, recibir resultados y referencias y conservar la procedencia de cada servicio y conjunto de datos.
  • El descubrimiento y la selección del proveedor, el registro, la propiedad y la unicidad quedaron deliberadamente fuera. La pregunta podía tener una forma común sin que el protocolo decidiera quién tenía autoridad para responderla.

A finales de los noventa, escribir en la barra de un navegador ya no significaba necesariamente escribir una URL. Los usuarios introducían nombres de empresas, personas, libros o lugares. Los portales podían convertir esas expresiones en navegación o búsqueda, pero integrar directorios especializados exigía interfaces propias.

El Common Name Resolution Protocol ofreció una interfaz compartida. RFC 3367, publicado en 2002 como Proposed Standard, describió mensajes XML con los que un cliente consultaba asociaciones previamente creadas entre una frase humana y recursos de Internet. Su objetivo no era inventar otro DNS ni imponer un directorio mundial.

El nombre común carecía de sintaxis obligatoria. A diferencia de un URI, no expresaba por sí mismo una estructura de identificación. A diferencia de un URN, la relación con el recurso no tenía que ser única ni persistente. Varias bases podían usar la misma expresión para registros distintos.

CNRP empezaba una vez elegido el lugar donde preguntar. El cliente podía solicitar una descripción del servicio, conocer las propiedades que aceptaba y enviar la consulta. La respuesta podía incluir descriptores de recursos, estados y referencias a otros servicios. Los objetos de servicio detallaban servidores y conjuntos de datos.

Esa procedencia era esencial cuando un intermediario combinaba resultados. Un portal podía preguntar a varios proveedores en serie o en paralelo, unir las respuestas y conservar la indicación del servicio y del conjunto que había originado cada elemento. Interoperabilidad no significaba borrar el origen.

El mínimo común incluía nombre, identificador local, URI del recurso y descripción. Idioma, geografía y categoría permitían acotar la solicitud. Sin embargo, funcionaban como pistas de mejor esfuerzo. La medida en que un servicio las entendía era un diferenciador, no una promesa de comportamiento idéntico.

Por eso una consulta CNRP no equivalía a un WHERE de SQL. Un proveedor podía devolver lo que consideraba más próximo a los criterios y avisar de propiedades ignoradas mediante un estado de éxito parcial. La norma coordinaba el sobre y ciertas señales, pero no el ranking, la cobertura ni cada taxonomía.

RFC 2972 había separado con claridad lo que el protocolo no resolvería: descubrimiento y selección de proveedores, administración, registro, propiedad y métodos para garantizar nombres únicos. Una implementación podía hablar con un servicio ya seleccionado. Elegirlo seguía siendo una decisión externa.

Ahí entraba la autoridad. Un navegador configurado con un directorio comercial y otro con un servicio regional podían enviar la misma frase y recibir dos enlaces conformes. El protocolo mostraba de dónde venía cada uno; no declaraba cuál era la respuesta universal.

La distinción entre espacios privados y públicos reforzaba el punto. En los nombres de personas, lugares u obras no existía una autoridad única de asignación. Dos servicios podían organizar las mismas cosas con categorías distintas. RFC 2972 incluso reconocía que palabras clave libres quizá no garantizaran interoperabilidad completa entre clasificaciones.

RFC 3368 convirtió esa frontera en sintaxis con el esquema go:. Una forma indicaba un servidor concreto. Otra expresaba una consulta sin servidor, destinada a los servicios configurados en el cliente. Dos máquinas podían copiar la misma cadena y obtener respuestas diferentes porque la selección institucional no viajaba necesariamente en ella.

El arranque de transporte sí tenía una regla común: clientes y servidores genéricos debían admitir HTTP en el puerto 1096 para el primer contacto. Luego un servicio podía anunciar alternativas. Saber cómo iniciar una conexión con un destino conocido no explicaba cómo se había descubierto ni por qué debía considerarse fiable.

Las referencias añadían otro tramo. El servidor podía entregar resultados y señalar otro servicio. El cliente debía registrar pares de servicio y conjunto de datos para detectar bucles. Si un destino referenciado no respondía, el resultado podía ser parcialmente satisfactorio, no una respuesta completa disfrazada.

La seguridad regresaba al problema de selección. RFC 3367 señaló ataques de intermediario, suplantación del objeto Service y denegación de servicio causada por la nueva indirección. Firmar el objeto ayudaba, pero verificarlo requería obtener una clave pública autorizada. Ese paso quedaba fuera de alcance porque dependía del descubrimiento.

La firma podía proteger una declaración después de elegir la raíz de confianza. No podía elegir esa raíz. La validez criptográfica no otorgaba por sí sola autoridad institucional.

El registro actual de IANA conserva go como esquema permanente y cita RFC 3368; RFC 3367 sigue figurando como Proposed Standard. Son comprobantes de coordinación, no un censo de navegadores, servidores, tráfico o usuarios. Las expectativas de integración descritas en RFC 2972 tampoco constituyen mediciones de adopción.

RFC 2396 y su sucesor RFC 3986 aportan la sintaxis general de URI. RFC 2276 y RFC 2483 estudian la resolución en torno a URN, y RFC 3401 presenta otra familia de descubrimiento delegado. Sitúan CNRP en una época de experimentación con identificadores y resolución, pero no prueban una sustitución operativa.

Los ensayos de Lu Heng proporcionan la lente declarada. “Minimum Initial Specification” ayuda a leer el pequeño núcleo común y las decisiones locales posteriores. “On Reality Layers” impide confundir una respuesta válida con la intención del usuario: conformidad, identidad del servicio, procedencia, asociación, acceso y propósito son capas distintas.

La arquitectura aceptó respuestas plurales y dejó rastros para entenderlas. Eso no eliminó el poder de quien fijaba la lista inicial de proveedores, las clasificaciones disponibles y las referencias que podían recorrerse. Un formato neutral reduce costes de integración sin neutralizar la distribución.

La lección histórica de RFC 3367 es esa separación. La red podía acordar cómo formular y transportar una pregunta. Acordar quién tenía derecho a responder exigía otra decisión, que el protocolo decidió no tomar.

Fuentes