El cliente mandaba sobre la ventana; el servidor, sobre la reacción: RFC 1073 y NAWS

Resumen

• La RFC 1073 permitió que el cliente comunicara anchura y altura en celdas de caracteres y enviara valores nuevos después de un cambio local. El servidor podía aceptar NAWS, no usar la información o cancelar futuras actualizaciones.
• Negociar la opción, recibir cuatro octetos, actualizar el estado del terminal, avisar a un proceso hijo y rehacer la presentación eran hechos diferentes. Ninguno convertía la geometría en identidad, píxeles, conformidad o prueba de que alguien vio la salida.

El terminal virtual de Telnet no prometía ancho de impresora ni longitud de página. Esa indefinición protegía la interoperabilidad básica: dos sistemas podían empezar desde un dispositivo imaginario común sin conocer todos los detalles del otro. Pero las estaciones gráficas de finales de los ochenta introdujeron una condición móvil. La aplicación Telnet vivía dentro de una ventana que el usuario podía cambiar mientras la sesión seguía abierta.

La RFC 1073 llamó NAWS a la opción 31. Su solución no fue negociar quién ganaba una disputa sobre el tamaño. Reconoció que no había tal disputa: el cliente controlaba por completo su ventana y el servidor necesitaba una descripción actual para manejar el cursor. El informe iba en una dirección; la decisión de usarlo pertenecía al otro extremo.

El estado de opción no era el estado de la pantalla

Un servidor enviaba DO NAWS para proponer el uso; un cliente dispuesto respondía WILL NAWS. DON'T y WON'T conservaban la negativa. La RFC 855 había establecido el patrón: primero se confirma que ambos lados entienden la opción; después una subnegociación transporta sus datos propios.

Esta secuencia permite separar pruebas. El acuerdo DO/WILL demuestra permiso y capacidad de conversación. No demuestra que el cliente haya enviado medidas. Un paquete NAWS demuestra que cuatro octetos llegaron a cierto punto del flujo. Tampoco confirma que el servidor los aceptara como estado local, que el hijo recibiera una señal o que la aplicación ajustara una sola línea.

La subnegociación llevaba dos octetos de anchura y dos de altura, en orden de Internet. Las cantidades describían caracteres, no píxeles, y podían alcanzar 65 535 por eje. El valor 255 tenía una regla adicional: como Telnet lo reservaba para IAC, cualquier 255 presente en los datos debía duplicarse. Una captura sin el contexto de desescape podía presentar cinco octetos donde el valor lógico solo contenía cuatro.

Cero significaba “no envío esta dimensión”. No significaba una pantalla con cero columnas o cero filas. El servidor podía adoptar un valor dependiente del sistema operativo, quizá apoyándose en el tipo de terminal obtenido mediante otra opción. La ausencia se conservaba como ausencia, en vez de inventar precisión.

Cada cambio añadía una generación

El ejemplo más útil de la RFC no está en la primera medida, sino en la segunda. El cliente comunica 80 × 24 y, después de que el usuario cambia la ventana, envía 80 × 64. No pide otra vez permiso. Tampoco recibe un acuse que diga “la aplicación ya se adaptó”. Solo añade una generación más reciente de su estado local.

Un sistema distribuido puede mantener ambas generaciones durante un intervalo. El entorno gráfico ya conoce la nueva altura; el cliente aún no ha enviado el mensaje; el servidor conserva el dato anterior; el proceso hijo todavía no ha tratado la notificación. La frase “el tamaño de la ventana” es ambigua si no identifica dueño, instante y fuente.

La información era expresamente orientativa. La RFC permitía que el servidor aceptara NAWS y no usara los valores. También reconocía sistemas incapaces de modificar el tamaño durante una sesión. Después de aceptar, un servidor podía enviar DON'T NAWS y detener las subnegociaciones posteriores. Ese mensaje gobernaba la conversación, no la ventana local: el cliente podía seguir cambiándola aunque el servidor dejara de escuchar.

NAWS corrigió una semántica de control

Las opciones anteriores NAOL y NAOP trataban por separado ancho de línea y tamaño de página. Eran bidireccionales y podían sugerir que el servidor tenía autoridad para controlar el ancho o la altura del cliente. Además, cada eje quedaba limitado a 253 caracteres y el propio documento las describía como poco usadas.

NAWS envió ambos ejes a la vez porque una ventana suele cambiar como rectángulo. Su mejora más profunda fue eliminar la autoridad imaginaria del servidor sobre un objeto local. El servidor podía pedir informes, pero no podía redimensionar la ventana mediante esa opción. El cliente declaraba una rejilla útil para presentación remota, sin certificar las dimensiones físicas del monitor.

Así se entiende el ejemplo de 300 × 24. No exige imaginar un monitor descomunal. Declara 300 columnas de caracteres. Confundir celdas con píxeles o con cristal físico sería sumar una afirmación que el protocolo nunca transportó.

El terminal no era una sola ficha de atributos

La RFC 930 definía el intercambio de tipo de terminal. El servidor solicitaba y el cliente respondía; recibir un nombre no obligaba a cambiar el procesamiento de inmediato. La RFC 1091 amplió ese mecanismo para recorrer varios modos de emulación. Era una conversación sobre capacidades y selección, no sobre la geometría actual.

La RFC 1079 trató la velocidad bajo el código 32. Una vez obtenido el permiso, el solicitante pedía una cadena ASCII con tasas de transmisión y recepción. El emisor no podía mandarla espontáneamente. NAWS, en cambio, dejaba que el cliente notificara un cambio local sin esperar otra petición y usaba dos ejes binarios.

El tipo podía orientar un valor por defecto cuando NAWS llevaba cero. La velocidad podía influir en relleno o interfaz. Ninguno reemplazaba la evidencia de anchura y altura. Mantener las opciones separadas evitaba que una etiqueta general de “terminal” adquiriera más autoridad que sus fuentes.

El registro de opciones Telnet de IANA conserva NAWS en 31 y TERMINAL-SPEED en 32. Es una prueba de asignación y referencia. No demuestra que un servidor actual implemente la opción, que la aplique correctamente o que una sesión concreta la haya negociado.

Del gestor de ventanas al proceso remoto

La RFC dibujó con palabras una cadena operativa. El sistema gráfico informa del cambio al cliente Telnet. En 4.3BSD, el proceso puede capturar SIGWINCH. Después envía NAWS. Al recibirlo, el servidor puede actualizar el terminal mediante ioctl y enviar una señal a su hijo, probablemente un intérprete de órdenes.

Cada paso tiene un responsable y puede fallar sin invalidar los anteriores. Un NAWS correcto no obliga al ioctl. Un estado actualizado no prueba la entrega de la señal. La entrega no garantiza que la aplicación la procese antes de emitir salida. La salida ajustada tampoco prueba que haya llegado a ojos humanos.

Esa cadena ofrece una guía de diagnóstico: comparar evento local, bytes transmitidos, decodificación, estado remoto, notificación y comportamiento de la aplicación. Reunir todo bajo un indicador “resize OK” sería más cómodo y menos verdadero.

Fuentes y límites

La RFC 1073 describe una propuesta de 1988 y un uso contemporáneo en Carnegie-Mellon, no una medición de adopción universal. Las RFC 854 y 855 fijan el marco de negociación. Las RFC 930, 1079 y 1091 explican atributos cercanos sin probar el uso de NAWS. El registro IANA tampoco establece tráfico ni conformidad actuales.

No hace falta atribuirle descendencia directa en SSH, interfaces adaptativas o escritorios remotos para reconocer su aporte. La opción hizo portable una observación limitada y dejó intacta la libertad local del receptor. El cliente era autoridad sobre su ventana; el servidor era autoridad sobre su reacción.