Resumen

  • RFC 2122 definió una URL para un servicio multimedia interactivo, no para un objeto de datos; el cliente VEMMI normalmente abría una sesión TCP continua en el puerto 575.
  • La URL podía seleccionar un servicio y llevar parámetros etiquetados, pero no usuario ni contraseña. El soporte del navegador, la autenticación y VEMMI_Open eran etapas posteriores.
  • application/vemmi cubría el transporte separado de objetos, incluidos objetos operativos ejecutables. Recibir, aprobar, ejecutar y obtener un resultado seguro exigían pruebas distintas.

Una dirección de servicio

Publicada como Proposed Standard en marzo de 1997, RFC 2122 definió el esquema de VEMMI, la interfaz mejorada hombre-máquina para servicios de videotex y recuperación multimedia. Su frase decisiva es inequívoca: la URL no designa un objeto de datos, sino un servicio multimedia interactivo.

La forma vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value> permitía nombrar host, puerto, servicio y pares atributo-valor. Si faltaba el puerto se usaba 575, aunque el cliente podía ignorar otro puerto explícito por seguridad. Los parámetros podían aportar contexto o pedir un procesamiento. Nada de ello demostraba resolución DNS, un listener, la existencia del servicio o la aceptación de los parámetros.

VEMMI solía mantener un enlace TCP/IP durante toda la sesión y usarlo para manejar objetos y devolver acciones del usuario. La Web aportaba el punto de encuentro; no absorbía el protocolo con estado.

La conversación empezaba después del clic

Tras conectar, el servidor podía pedir service:, username: y password:. El cliente contestaba con el servicio de la URL, valores locales o datos solicitados al usuario. Hasta recibir VEMMI_Open, el terminal seguía en modo estándar compatible con videotex o telnet.

RFC 2122 prohibía usuario y contraseña dentro de la URL. Por eso selección e identidad ocupaban capas diferentes. Sus ejemplos de 200 OK y 401 Unauthorized ilustraban posibles ramas, no incidentes ni mediciones reales. Un enlace pulsado, un helper lanzado, un TCP abierto, una credencial aceptada y una sesión VEMMI iniciada eran cinco recibos, no uno.

Un esquema desconocido podía no llegar al servicio

El soporte podía estar integrado en el navegador o residir en un programa asociado. Sin él, un navegador podía rechazar el esquema; otro podía interpretarlo como URL relativa, enviarlo al servidor HTTP de la página y recibir “not found”. La existencia de vemmi:// en HTML no probaba siquiera que el equipo tuviera un manejador.

La RFC sugirió descargar el cliente por separado, reconocer la petición relativa errónea o usar Accept: application/vemmi como indicio de decodificador. No midió cuántos navegadores hicieron nada de eso. El texto es una propuesta técnica, no una encuesta de adopción.

El transporte de objetos era otra función

El tipo application/vemmi permitía transportar objetos por HTTP, correo u otros medios sin abrir la sesión continua. También podía llevar un archivo de texto con la URL que debía activarse. El esquema iniciaba un camino hacia un servicio; el tipo de medios describía un objeto para transporte y decodificación.

IANA mantiene hoy vemmi como esquema URI permanente, application/vemmi como tipo de medios y el puerto 575. Son hechos registrales, no telemetría. No prueban mantenimiento, listener activo, tráfico, interoperabilidad ni uso.

El código necesitaba su propio consentimiento

Los objetos de metacódigo podían contener secuencias de órdenes; los objetos operativos podían ser programas ejecutables en el cliente. La RFC recomendó desactivar su ejecución automática o exigir autorización previa del usuario.

Así, entregar no era autorizar. Identificar el tipo, descargar, decodificar, aprobar, ejecutar y verificar el resultado eran controles independientes. La propia RFC calificaba de inseguro su mecanismo de usuario y contraseña y lo conservaba por compatibilidad. Esa es una observación histórica, no una recomendación actual.

RFC 1738 ya permitía que cada esquema definiera su método de acceso. RFC 2122 muestra una consecuencia concreta: el navegador podía abrir la puerta a un runtime con estado. La idea de Running-Code Primacy impide confundir esa definición con ejecución real.

El registro histórico correcto es una secuencia: nombrado, reconocido, despachado, conectado, seleccionado, autenticado, abierto, entregado, aprobado, ejecutado y observado. “El enlace funcionó” borra justamente los límites que RFC 2122 dejó a la vista.

Fuentes