Resumen

  • RFC 1116 situó en el cliente la edición de líneas y parte de la traducción de señales. Así sustituyó tráfico por tecla por unos pocos paquetes por línea y dio respuesta local en enlaces lentos.
  • DO/WILL permitía negociar; MODE_ACK confirmaba bits de edición y señales; SLC_ACK aceptaba una asignación de carácter. Ninguno confirmaba una orden de aplicación.
  • Un terminador o una condición FORWARDMASK podía liberar el búfer. El prefijo dejaba de ser editable, pero seguía sin demostrar llegada, interpretación, autorización o efecto en el servidor.

El terminal dejó de preguntar por cada tecla

RFC 1116 justificó Linemode con dos contabilidades. En un enlace de gran demora, esperar el eco remoto de cada carácter hacía frustrante la escritura. En redes cobradas por paquete, dos paquetes por carácter también tenían precio. Editar en el cliente reducía el intercambio a unos pocos paquetes por línea.

Había además una contabilidad de cómputo. Ciertas supercomputadoras no estaban diseñadas para procesar entradas unitarias con eficiencia. Un frontal podía ocuparse de borrar caracteres, formar la línea y traducir señales, dejando el cálculo vectorial a la máquina distante.

La consecuencia probatoria era estructural. La pantalla podía reaccionar aunque el servidor aún no supiera que existía la línea. El sistema cercano observaba edición; el lejano decidiría después sobre el texto recibido.

El registro del RFC Editor conserva la propuesta de agosto de 1989 y señala que fue sustituida. El IETF Datatracker mantiene el expediente. RFC 1184, de octubre de 1990, añadió bits de modo y caracteres de edición visual, pero mantuvo la asignación principal de trabajo al cliente.

El permiso era anterior al modo

La RFC 855 ordenaba las opciones Telnet en dos fases. Primero DO y WILL establecían que ambos extremos podían hablar de una opción. Después, la subnegociación llevaba parámetros. DONT o WONT permitían abandonar la conversación.

Linemode comenzaba con WONT y DONT como valores predeterminados. Una conexión Telnet no implicaba edición local. Un DO/WILL satisfactorio tampoco activaba por sí solo EDIT: únicamente abría la puerta a los submodos.

MODE colocaba EDIT y TRAPSIG. Normalmente el servidor proponía el cambio y el cliente respondía. MODE_ACK resolvía el estado común. EDIT indicaba quién procesaba la línea; TRAPSIG, quién convertía ciertos caracteres en órdenes Telnet. El acuse hablaba de esa máscara, no de una entrada posterior del usuario.

Esta diferencia evita una falsa progresión: capacidad, configuración y resultado no son tres grados de certeza sobre la misma acción. Cada uno pertenece a un objeto distinto.

El límite editable podía adelantarse

Con EDIT activo, la línea se formaba localmente. Los borrados actuaban sobre el búfer cercano y un terminador normal enviaba la versión ya editada con CR LF. Hasta entonces, ninguna corrección necesitaba viajar para deshacer un carácter en el servidor.

FORWARDMASK permitía al servidor señalar caracteres que debían despachar lo acumulado. SLC_FORW1 y SLC_FORW2 ofrecían otros dos límites. La RFC 1184 incluso permitía que un cliente con un controlador menos preciso aceptara la petición y enviara ante más caracteres de control que los enumerados.

La negociación fijaba una obligación mínima, pero dejaba una superficie local de implementación. Por eso el historial necesita el conjunto de reenvío efectivo, no sólo el solicitado. También necesita el instante exacto: después de transmitir un prefijo, ya no podía editarse esa parte.

No obstante, “ya no editable” sólo describía una decisión local irreversible. Los bytes aún debían cruzar TCP, llegar al intérprete Telnet, ser entregados al proceso, pasar su sintaxis y su política, y provocar o no una operación. Nada en el búfer veía esa secuencia.

El mapa de teclas no era un recibo de acciones

SLC, Set Local Characters, negociaba una función, modificadores y el carácter ASCII que la representaba. Sus niveles diferenciaban ausencia de soporte, valor inmutable, valor explícito y valor predeterminado. SLC_ACK significaba acuerdo con una asignación.

Ese acuse cerraba la discusión de configuración. No certificaba que el usuario hubiese pulsado la tecla ni que la traducción Telnet hubiese llegado. Tampoco certificaba que el proceso remoto entendiera la función.

La RFC 1184 permitía ignorar ABORT, EOF o SUSP cuando el sistema no ofrecía esa capacidad. Las banderas para vaciar entrada o salida eran asesoras, y la interfaz podía prevalecer sobre ellas. Un nombre de control no garantizaba que se interrumpiera un proceso, se notificara fin de archivo o se descartaran determinados bytes.

Ver el carácter no demostraba el viaje

RFC 857 separaba el eco que un extremo realiza para el otro de la decisión local de hacerse eco a sí mismo. Linemode aprovechaba justamente esa autonomía. La respuesta inmediata del CRT era una observación del cliente.

El flujo de salida también quedó fuera del modo. RFC 1116 y RFC 1184 remitían a RFC 1080 para el control de XON/XOFF entre el proceso Telnet del usuario y su terminal. Aquella opción tenía consentimiento y estado propios. No era edición, suspensión de la aplicación, ventana TCP ni congestión.

Mantener estas máquinas separadas impedía que “el terminal respondió” adquiriese un significado universal.

El protocolo terminaba antes del resultado empresarial

El registro de opciones Telnet de IANA conserva el número 34 y remite a RFC 1184. El registro permite interpretar el número; no mide sesiones ni certifica implementaciones.

RFC 854 aporta el NVT y el lenguaje de control. Puede transportar una línea o una señal hasta el proceso Telnet. No define la autorización de una orden en la aplicación conectada. RFC 1184 declara, además, que no discute cuestiones de seguridad.

Una prueba completa se construye después: búfer terminado, prefijo emitido, bytes recibidos, Telnet decodificado, proceso localizado, entrada aceptada, operación iniciada, efecto confirmado y respuesta asociada. Linemode hizo barato el primer tramo. Nunca sostuvo que el último hubiese ocurrido.

Fuentes