Resumen

  • El RFC 1043 documentó en 1988 la implementación DODIIS de la opción TELNET Data Entry Terminal. Según sus autores, una pulsación con eco remoto podía viajar en un datagrama y regresar en otro.
  • DET daba al terminal un formulario de pantalla completa con campos editables localmente. Aplicación y terminal negociaban las funciones comunes, se cedían el turno con GO-AHEAD y podían devolver solo campos «modificados», entre ellos algunos marcados así por la aplicación.

Una letra llevaba demasiado equipaje

La introducción del RFC 1043 cuenta un viaje ridículamente pequeño: una tecla genera un datagrama con sus cabeceras TCP/IP y el carácter; el host devuelve otro datagrama para mostrar el eco. La Defense Intelligence Agency buscaba acceso de pantalla completa a aplicaciones sobre una red de conmutación de paquetes. El documento informaba de implementaciones DET en IAS, MVS, OS86 y UNIX, mientras VM y VMS seguían en desarrollo. Los ordenadores diferían; la persona que llenaba una ficha esperaba que la ficha tuviera forma de ficha, no de conversación a distancia letra por letra.

La opción de terminal de entrada de datos provenía del RFC 732. El RFC 1043 llegó cuando varios grupos DODIIS habían construido versiones independientes y surgía la duda de si podrían entenderse entre sí. Un formulario veloz en un único equipo y roto en el siguiente solo cambia tráfico de red por llamadas al servicio técnico. La nueva especificación fijó un mínimo común, describió las capacidades adicionales y explicó cómo se pasaban el turno la aplicación y el terminal.

El modelo parecía un terminal de formularios semidúplex. La pantalla rectangular contenía zonas protegidas y campos donde el usuario podía escribir. El teclado editaba esos campos localmente; teclas de función y selección de campos ofrecían otras respuestas. El tamaño inicial era de 80 caracteres por 24 líneas, y los hosts de usuario debían admitir entre 24 y 48 líneas. La aplicación componía los campos mediante posición, tamaño, atributos y contenido. Cuando terminaba de preparar la pantalla, enviaba GO-AHEAD y desbloqueaba el teclado. La persona rellenaba el formulario o usaba una función habilitada; el terminal enviaba su respuesta y otro GO-AHEAD. El permiso para hablar iba y venía como un testigo de relevos.

Antes de cualquier formulario, ambos extremos tenían que aceptar DET. La opción tenía el número 20 de TELNET y se negociaba en ambas direcciones con DO y WILL. Si fracasaba el acuerdo, el estado por defecto era WONT DET -- DONT DET: la sesión seguía como terminal virtual de red ordinario. Al entrar en DET, el RFC pedía rechazar o terminar opciones en conflicto como Echo, Suppress Go-Ahead y Binary. El nuevo modo de turnos no podía convivir alegremente con hábitos antiguos que enviaban ecos por su cuenta.

El acuerdo sobre DET abría otra negociación. Cuatro subcomandos de «facilities» declaraban capacidades de edición, borrado, transmisión y formato. El terminal exponía lo que ofrecía y la aplicación lo que deseaba. Solo la intersección lógica de sus mapas quedaba disponible. Para la intensidad visual regía el menor nivel ofertado. Ninguna función opcional se usaba antes de pactarla, y cualquiera de las partes podía desactivarla más tarde. Los bits reservados tenían que viajar a cero, de modo que una futura opción no apareciera aceptada por accidente.

Incluso había que recordar quién había comenzado cada negociación: dos máquinas demasiado educadas pueden contestarse hasta el fin de los tiempos.

El ahorro se veía al devolver la ficha. La aplicación podía pedir toda la pantalla, los campos sin protección o los modificados, mediante TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED y TRANSMIT-MODIFIED. Si no pedía nada expresamente, los atributos Modified y Protection ya negociados elegían una respuesta por defecto que buscaba enviar la menor cantidad permitida. El formulario permanecía visible mientras la aplicación preparaba el siguiente paso. Las teclas habían trabajado cerca de la persona y solo después viajaban como campos.

La palabra «modificados» tenía trampa. El RFC 1043 exigía que TRANSMIT-MODIFIED devolviera tanto los campos efectivamente alterados por el usuario como los que llevaban el atributo Modified. Una respuesta podía incluir un campo que la persona nunca tocó. La aplicación tenía que leer las reglas de esa ficha antes de reconstruir la actividad humana. La advertencia aparece en un recuadro: una nota amable para quien acabaría investigando un dato aparentemente inexplicable.

El conjunto mínimo de comandos DET no alcanzaba para todos los formularios DODIIS. Los hosts de usuario debían implementar los subcomandos indicados y los atributos que el equipo soportaba o que el software podía emular con facilidad. Los servidores implementaban lo que exigían sus aplicaciones. Una tabla repartía responsabilidades de envío y recepción. El objetivo era que equipos heterogéneos compartieran un idioma operativo sin fingir que todos tenían el mismo teclado o la misma pantalla.

El RFC 1043 puso un formulario donde antes había una procesión de ecos. La persona editaba cerca de su teclado; las máquinas acordaban sus capacidades; el retorno transportaba lo que correspondía. La red dejó de asistir a cada pulsación porque los dos extremos aprendieron a colaborar a escala de una ficha completa.