Resumen

  • RFC 1041 propuso una sola opción 3270-REGIME; RFC 1576 registró que casi nadie la implementó y describió la práctica real basada en Terminal-Type, Binary y EOR.
  • Ese ensamblaje podía establecer el formato 3270 y delimitar cada bloque. No asignaba una identidad LU visible, no entregaba el BIND SNA y no correlacionaba una respuesta de procesamiento con los datos enviados.
  • TN3270E añadió después tipo/nombre de dispositivo, BIND y respuestas como funciones negociadas por separado. Ninguna de ellas autenticaba por sí misma al usuario ni probaba el resultado final.

El estándar de una pieza no ganó la instalación

Un terminal 3270 no hablaba como el NVT de Telnet. Su representación era EBCDIC y su intercambio estaba organizado en bloques. Hacía falta acordar qué emulación usar, transportar ocho bits sin alterar el contenido y marcar dónde terminaba cada comando.

RFC 1041 quiso reunir todo en la opción 29, 3270-REGIME. El cliente ofrecía una lista de regímenes por orden de preferencia, el servidor elegía uno y el acuerdo implicaba Binary y IAC EOR. Una lista vacía permitía volver a NVT ASCII.

El documento también fijó un momento de transición. El cliente debía dejar de aceptar entrada del usuario al empezar a negociar. El servidor debía evitar enviar datos y vaciar lo pendiente antes de confirmar el nuevo régimen. Cada extremo cambiaba su intérprete al enviar o recibir la selección. La precaución reconocía un riesgo básico: los mismos bytes adquieren otra sintaxis si la frontera se mueve.

Pero la forma ordenada no dominó el código instalado. RFC 1576 dice que muy pocos desarrolladores y proveedores implementaron RFC 1041. Su registro oficial sitúa el documento en enero de 1994 y lo clasifica como Informational. No es una medición universal, pero sí la razón documental para observar el convenio que funcionaba.

La práctica sumó tres recibos modestos

TN3270 tradicional combinaba el marco de Telnet con Terminal-Type, Binary Transmission y End of Record. El servidor pedía un tipo; el cliente declaraba una emulación. Binary habilitaba el camino de ocho bits. EOR separaba comandos 3270 completos.

Ninguna opción contenía el veredicto completo. La composición formaba el régimen de facto. RFC 1576 permitía negociar en cualquier orden. Una vez presentes el tipo adecuado, Binary y EOR, circulaban bloques terminados en IAC EOR. Si el servidor retiraba Binary o EOR, la sesión dejaba de cumplir TN3270 y el cliente volvía a interpretar los datos como NVT ASCII.

La utilidad dependía de no pedirle más a cada señal. Binary conservaba octetos. EOR marcaba una frontera. Terminal-Type informaba una representación. El servidor seguía eligiendo cómo traducir esa fachada hacia un host SNA o no-SNA.

La pantalla no revelaba la unidad lógica

Terminal-Type era asimétrico. El servidor decidía cuándo preguntar; el cliente recorría sus alternativas. Al declarar un tipo, el cliente podía tener que cambiar su modo de emulación. Recibir el nombre no obligaba al servidor a cambiar de inmediato su procesamiento.

Por eso un modelo 3278 y su tamaño de pantalla no eran una identidad física ni una asignación de sesión. El sufijo -E sugería soporte de structured fields y atributos extendidos, pero RFC 1576 advertía que los servidores no lo interpretaban todos igual.

La diferencia se hacía mayor detrás de una conexión SNA. Allí un terminal tenía una sesión con la aplicación y otra con el System Services Control Point. TN3270 presentaba una sola conexión Telnet. El cliente no podía pedir un device-name concreto ni descubrir el LU name que el servidor usaba ante el host. La dirección IP era apenas el dato más parecido disponible; no nombraba la misma cosa.

Muchas aplicaciones centrales podían comportarse de modo distinto según el nombre de red del terminal. Un tipo de emulación correcto no demostraba que se hubiera asignado el recurso lógico esperado.

Un bloque completo todavía podía ser ignorado

El flujo 3270 necesitaba EOR porque el comando y sus datos no llevaban una longitud exterior. Cuando llegaba IAC EOR, el receptor conocía el límite del bloque. No sabía aún el resultado de procesarlo.

RFC 1576 incluyó entre las carencias la respuesta positiva/negativa de SNA. Una positiva indicaba que el dato anterior terminó de procesarse. Una negativa podía comunicar un comando inválido o una avería mecánica en el cliente. TN3270 tradicional no transmitía ese recibo: el dato se suponía tratado o ignorado.

La escalera probatoria no admite atajos: conexión TCP, octetos recibidos, EOR encontrado, comando interpretado, pantalla actualizada, impresora actuando, aplicación respondiendo y persona entendiendo son eventos distintos.

Tampoco una prueba de presencia cerraba el hueco. NOP o Timing Mark podían ayudar al servidor a descubrir que el cliente seguía alcanzable. NOP no esperaba una respuesta de aplicación; un proceso muerto podía revelarse sólo por error de envío TCP. Alcanzable no significaba sano, atento ni terminado.

Las teclas especiales pertenecían a la pasarela

ATTN solía mapearse a Telnet BREAK para pedir que la aplicación interrumpiera su trabajo. El servidor tenía que traducirlo al mecanismo apropiado. Un servidor no-SNA podía ignorarlo.

SYSREQ variaba aún más. Algunos servidores usaban Telnet Interrupt Process; otros, una Test Request. En SNA, SYSREQ alternaba entre la sesión de aplicación y la sesión SSCP. Como el cliente no recibía directamente ese segundo formato, la pasarela debía convertirlo, administrarlo por sí misma o renunciar a la función.

La pulsación, el comando Telnet, la traducción, el evento SNA y la interrupción efectiva merecían registros separados. “Tecla enviada” no era prueba de que el host hubiera obedecido.

TN3270E hizo explícita la deuda

RFC 1646 y RFC 1647 prepararon la ampliación. RFC 2355, cuyo registro la ubica en el Standards Track en 1998, consolidó TN3270E.

La nueva opción negociaba primero el tipo y, de manera opcional, un recurso o nombre de dispositivo. El servidor devolvía el nombre asignado o una causa de rechazo, como nombre desconocido, dispositivo ocupado o incompatibilidad. Después se acordaba una lista de funciones.

BIND-IMAGE podía comunicar el comienzo y fin de la sesión SNA con la aplicación. RESPONSES añadía encabezado, política de respuesta y número de secuencia para vincular un resultado positivo o negativo al bloque preciso. SYSREQ y las funciones de impresora se mantenían como capacidades diferentes. La lista incluso podía ser vacía: basic TN3270E.

La ausencia no adquirió un único significado. Un bloque podía pedir ninguna respuesta, respuesta sólo por error o respuesta siempre. Si RESPONSES no se negociaba, el número de secuencia era irrelevante. Si faltaba BIND-IMAGE, el cliente no obtenía el BIND. Y si un extremo rechazaba TN3270E, se podía volver al TN3270 tradicional.

RFC 2355 también dejó un límite de seguridad: TN3270E no era más seguro que Telnet ordinario. Aceptar un device-name no respondía si el usuario estaba autorizado a emplearlo.

La implementación real tampoco era autoridad total

La secuencia histórica evita dos dogmas. Publicar 3270-REGIME no obligó al mundo a adoptarlo. Ver que tres opciones funcionaban no convirtió su salida en identidad y resultado completos. Añadir TN3270E no borró el modo anterior ni garantizó sus funciones opcionales.

El texto de Heng Lu sobre la primacía del código en ejecución dirige la mirada al sistema que realmente actúa. Su propuesta de una especificación inicial mínima con decisiones locales explica el valor económico de reutilizar acuerdos pequeños. Su ensayo sobre capas de realidad impide fundir presentación, sesión, identidad y consecuencia. Es una lectura editorial posterior, no una atribución histórica a los autores.

RFC 1576 deja una disciplina sencilla. El tipo nombra la emulación; Binary conserva los bytes; EOR cierra el bloque. El LU, el BIND, el procesamiento, la interrupción y el resultado final necesitan cada uno su propio recibo.

Fuentes