Resumen

  • RFC 1079 separó el permiso para discutir TERMINAL-SPEED, la petición posterior y la respuesta con dos velocidades del terminal.
  • La cadena recibida podía orientar una elección local de pantalla; no demostraba un hecho de red ni autorizaba una política de transporte.

El número no describía el cable

Los terminales y módems directamente conectados imponían costos visibles a los programas de su época. Muchos sistemas guardaban su velocidad para decidir cuántos caracteres de relleno introducir o para adaptar una interfaz a un terminal lento. RFC 1079 quiso llevar una información semejante a una sesión Telnet. No quiso convertir Telnet en un instrumento de medición del trayecto.

Por eso una respuesta como 9600,100 debe leerse con cuidado. Es una cadena NVT ASCII con las representaciones decimales de las velocidades de transmisión y recepción del terminal, separadas por una coma. No es una sonda. No informa lo que ve un enrutador, no muestra la capacidad disponible, no registra pérdidas y no promete qué hará TCP. Que parezca una cifra técnica no ensancha la autoridad que tiene.

La utilidad del dato era más modesta: un programa podía preferir una presentación cautelosa. Si se necesitaban conclusiones sobre rendimiento, entrega o experiencia de una persona, había que observar esas cosas por separado. Mantener el número en su capa evita que una elección de interfaz sea presentada después como un juicio sobre todo el sistema.

Antes de informar, había que convenir y pedir

RFC 854 estableció el marco de Telnet. El Network Virtual Terminal funciona como representación común, mientras WILL, WON'T, DO y DON'T permiten pactar convenciones adicionales. RFC 1079 aplica ese mecanismo a la opción 32, TERMINAL-SPEED.

El estado por defecto es no intercambiar nada: WON'T TERMINAL-SPEED y DON'T TERMINAL-SPEED. WILL solo manifiesta disposición a enviar información más adelante; DO solo manifiesta disposición a recibirla. Ninguno de los dos lleva la velocidad. Son permiso para un diálogo futuro, no el resultado del diálogo.

Tras el intercambio de ambos, quien envió DO puede solicitar el dato mediante IAC SB TERMINAL-SPEED SEND IAC SE; solo quien envió WILL puede transmitirlo con IAC SB TERMINAL-SPEED IS ... IAC SE. La respuesta no puede aparecer espontáneamente. La regla delimita quién inicia la consulta y quién declara una característica. No convierte a ninguno en autoridad sobre la ruta ni en verificador de la afirmación.

La gramática también es estricta: dos enteros decimales, una coma, sin ceros iniciales ni caracteres sobrantes. Eso permite analizar el mensaje de manera compatible. No prueba que el equipo descrito sea real, que el módem esté sincronizado, que el camino tenga esa velocidad o que una pantalla haya sido leída.

La decisión segura seguía siendo local

RFC 1079 considera sistemas que solo admiten unas pocas velocidades discretas. Sugiere escoger la más próxima en una dirección segura; para padding, redondear hacia arriba puede ser preferible a poner demasiado poco. Es una sugerencia sobre cómo un programa interpreta una entrada remota dentro de sus propios límites. No ordena cambiar la línea, reservar capacidad, modificar un router ni gobernar la congestión.

El programa puede guardar la respuesta original, indicar qué valor local eligió y volver a pedir el dato después. Esa trazabilidad deja clara la diferencia entre un atributo entregado y la consecuencia que el software eligió. RFC 930, el modelo de opción de tipo de terminal citado por RFC 1079, comparte la misma disciplina: la información se entrega en subnegociación y su transmisión no equivale por sí sola a un cambio de procesamiento.

Lo que una respuesta no puede probar

1200,1200 demuestra, como máximo, que un participante emitió esos caracteres en el intercambio definido. No demuestra conexión física a esa velocidad, sincronía de módem, capacidad TCP, ausencia de pérdidas, legibilidad de la pantalla, identidad del usuario ni éxito de una operación. Tampoco basta para afirmar que Telnet esté desplegado hoy en un sistema concreto.

La escalada que debe evitarse es conocida: atributo local, aparente medición, supuesta política de red. RFC 1079 solo cubre el primer paso. Cualquier paso posterior requiere observación, responsabilidad y autoridad propias.

Fuentes y límite de evidencia

La fuente principal es RFC 1079; RFC 854 aporta NVT y el marco de negociación; RFC 930 es la comparación histórica de la forma SEND/IS; RFC 1123 sitúa RFC 1079 en las referencias Telnet. Ninguno documenta despliegue actual, una implementación identificada, capacidad de enlace, autorización, identidad o resultado de aplicación.