Resumen

  • La RFC 860, publicada por Jon Postel y Joyce Reynolds en mayo de 1983, definió TIMING-MARK como la opción 6 de TELNET. Un extremo pedía DO TIMING-MARK y el otro podía devolver WILL TIMING-MARK en un lugar preciso del flujo, después de atravesar los búferes que mediaban entre proceso y terminal.
  • El ejemplo más revelador era una orden errónea seguida por caracteres escritos antes de recibir respuesta. El servidor descartaba esa entrada adelantada hasta encontrar la marca devuelta. Desde allí podía volver a interpretar lo escrito tras la señal de error visible para la persona.

El usuario teclea una orden y, sin esperar, empieza la siguiente. El servidor descubre que la primera está mal escrita. Enseña un signo de interrogación, pero la segunda orden quizá ya duerme en el ordenador del usuario, circula por la conexión o se acumula en la entrada del servidor. Leerla como una instrucción nueva sería como corregir una frase mientras alguien continúa dictando la página anterior. La pregunta de la RFC 860 era terrenal: ¿dónde termina exactamente lo que conviene borrar?

TELNET comunicaba dos procesos en ambas direcciones. Su especificación principal describía el intercambio, mientras que las reglas para opciones dejaban proponer funciones adicionales. TIMING-MARK daba a una de esas opciones un trabajo de oficina muy concreto. La palabra «timing» podía sugerir un reloj; lo decisivo era la posición de una señal en dos flujos de datos con colas a ambos lados.

El servidor enviaba IAC DO TIMING-MARK. Si el otro extremo colaboraba, insertaba IAC WILL TIMING-MARK en el punto adecuado de la respuesta. El documento describe cómo la marca cruza el búfer de salida de aquel extremo hacia el terminal y regresa por su búfer de entrada. Cuando la respuesta llega al servidor, ambos tienen una frontera de ida y vuelta. El servidor puede saber qué caracteres pertenecían al tramo anterior y cuáles se originaron después de que el usuario hubiera visto la advertencia.

La secuencia del ejemplo está escrita casi como una pequeña obra de teatro. Primero, retorno de carro, salto de línea y signo de interrogación. Luego, DO TIMING-MARK y un mensaje de error. Mientras espera WILL, el servidor lee y tira la entrada que vaya llegando. Tras la marca, vuelve a tomar las teclas en serio. La frontera prevista cae justo antes del primer carácter que el usuario escribió después de ver el signo de interrogación. De esa manera, una corrección consciente sobrevive y la segunda orden prematura acaba en la papelera.

Hay una cuestión de autoridad escondida en la basura. La RFC 860 asigna el descarte al extremo que solicitó la marca. El par remoto coloca una referencia fiable y la devuelve; el solicitante decide qué parte de su propia entrada elimina. Por eso el recurso funciona también al revés. Si al terminal le molesta una salida antigua del servidor, puede pedir la marca, dejar de mostrar esa salida hasta recibir WILL y reanudar la presentación cuando el servidor ya ha visto la nueva petición.

Las respuestas de la negociación no tienen todas la misma fuerza. WILL asegura la colocación de la señal. WON'T rehúsa esa garantía y, aun así, confirma que el otro extremo recibió los datos anteriores. DON'T comunica que se ignoró un WILL previo. El comportamiento normal de partida carecía de sincronización explícita. El documento enumera también la medición de un recorrido de ida y vuelta como posible uso; la señal ofrece un punto reconocible para observarlo.

Postel y Reynolds pensaron incluso en alguien que se adelantara a la petición. El equipo del usuario podía emitir WILL en un punto elegido por él y permitirle seguir escribiendo; más tarde tendría que gestionar la solicitud que acabaría llegando. Esa excepción deja ver el verdadero problema: la experiencia de una persona y el estado de las colas de dos máquinas nunca están perfectamente alineados. Para reanudar la conversación, hacía falta una señal que ambas pudieran reconocer.

Una errata de teclado parecía un incidente pequeño. En una sesión con entrada adelantada podía decidir el destino de varias órdenes posteriores. TIMING-MARK convirtió «después de que el usuario vio el error» en una frontera que el servidor podía usar. La máquina pedía un punto de referencia y se encargaba de limpiar su propia mesa.