Resumen

  • La RFC 1921 repartió una sesión de terminal VIP entre tres direcciones: pantalla, impresora y copia impresa de la pantalla. Cada dirección mantenía una sola petición sin resolver.
  • Una segunda petición dirigida a la misma ventanilla se borraba; su respuesta PROTOCOL-VIOLATION debía enviarse después de contestar la primera, de modo que el orden siguiera identificando cada operación.
  • La negociación Telnet y EOR daban gramática y límites. No convertían ACK, BUSY, READY ni un nombre de Mailbox en identidad, autorización o resultado físico.

La cola que el protocolo nunca prometió

Cuando una impresora dice que está ocupada, es fácil imaginar que el siguiente trabajo espera. TNVIP no permitía esa suposición. Si el emisor enviaba otra petición de impresión antes de recibir la respuesta de la anterior, el receptor borraba los nuevos datos. El estado BUSY describía pérdida, no una plaza en cola.

La RFC 1921 apareció en marzo de 1996 como documento Informational. Definía un perfil Telnet para emular terminales Visual Information Projection de Bull, equipos que trabajaban por bloques y podían manejar una impresora asociada. Una pasarela TNVIP conectaba esa estación con un Terminal Manager y, normalmente, con aplicaciones DSA.

La especificación no confundió transportar un bloque con tramitarlo. Primero creó ventanillas separadas y después definió qué podía estar pendiente en cada una.

Dirección antes que estado

Todo mensaje TNVIP llevaba una cabecera fija de dos octetos. El primero era la dirección: 0x60 para la pantalla, 0x68 para la impresora y 0x69 para la impresión de una copia de pantalla. El segundo contenía el comando y dos bits de tipo.

El tipo cero era una indicación, que no esperaba respuesta. El tipo uno era una petición y abría una obligación de responder en la misma dirección. El tipo dos era la respuesta que cerraba esa obligación. El tipo tres hacía dos cosas a la vez: respondía positivamente al trámite vigente y planteaba uno nuevo.

Por eso un código aislado no bastaba. Había que leer dirección, comando, tipo y petición pendiente. ACK en la pantalla podía confirmar datos o aceptar el paso a estado LOCAL. READY pertenecía a una consulta de estado de impresora. La misma conexión podía contener movimientos legítimos en una dirección mientras otra permanecía bloqueada.

El error esperaba para no contestar la pregunta equivocada

La regla central decía que no se podía abrir otra petición en una dirección antes de la respuesta actual. Si ocurría, el receptor eliminaba la segunda. Sin embargo, debía reservar el aviso PROTOCOL-VIOLATION hasta haber enviado la respuesta a la primera.

El retraso protegía la asociación. Al no existir un identificador de transacción, la siguiente respuesta correspondía por definición al único trámite abierto. Permitir que la infracción adelantara al resultado rompería esa definición. El emisor ya no sabría si el error negaba la primera acción o denunciaba la segunda.

El diseño pagaba con menos paralelismo. A cambio, cada extremo podía validar el orden usando solo tres estados locales. No necesitaba una autoridad de sesión que numerara y conciliara operaciones. LDAP eligió más tarde otra solución para otro entorno: permitir intercalado y usar Message IDs. La diferencia no es modernidad contra atraso, sino dos presupuestos distintos de estado compartido.

El terminal se declaraba; el usuario no quedaba probado

TNVIP comenzaba únicamente después de negociar Terminal-Type y End-of-Record. El tipo de terminal podía llevar el modelo seguido de @Mailbox-name. Ese nombre pedía un punto de acceso concreto en el servidor; su ausencia permitía uno genérico. En una pasarela DSA se limitaba a doce caracteres y se normalizaba a mayúsculas.

El valor servía para encaminar la sesión hacia una declaración lógica, quizá una estación con impresora o una composición particular de dispositivos. No era una credencial. RFC 1091 define el intercambio del tipo, no una prueba de posesión. La propia RFC 1921 dejó la seguridad fuera y anticipó que la autenticación futura tendría que decidir si un usuario podía utilizar un terminal específico.

Binary Transmission, descrita en RFC 856, conservaba ocho bits cuando hacían falta. Suppress-Go-Ahead, en RFC 858, cambiaba cómo se coordinaba el turno de envío. Ambas opciones afectaban al canal. Ninguna ascendía a un nombre de persona ni a una autorización de negocio.

EOR cerraba el sobre, no el expediente

Los dispositivos VIP acumulaban un bloque antes de transmitirlo. TNVIP usó IAC EOR para marcar el final de cada mensaje. RFC 885 daba esa herramienta al Telnet base de RFC 854.

Un bloque completo seguía necesitando una decisión de dispositivo. Podía procesarse, fallar, ser borrado por estado LOCAL, quedar abortado por el operador o recibir una purga. La frontera de bytes no decía cuál de esas ramas ocurrió.

Incluso el orden de control tenía un hueco. La RFC desaconsejaba insertar comandos Telnet dentro de un mensaje TNVIP porque una implementación podía procesarlos en el acto o después del bloque. Para eliminar esa variación, debían viajar entre mensajes. Una sintaxis delimitada no siempre fija el momento semántico de todo lo que contiene.

Ocho respuestas para no fabricar una sola verdad

ACK, ERROR, BUSY, ABORTED, PURGED, NOT-AVAILABLE, PROTOCOL-VIOLATION y UNKNOWN-COMMAND no eran adornos. Separaban procesamiento correcto, error del dispositivo, rechazo por ocupación, intervención del operador, cancelación todavía posible, dispositivo inexistente, secuencia ilegal y comando desconocido.

Una indicación con dirección o comando desconocidos podía borrarse sin respuesta porque nadie esperaba cierre. Una petición desconocida sí requería contestación. La diferencia residía en la obligación que el emisor había abierto, no en la rareza de los octetos.

El caso de BUSY muestra por qué se debe conservar el contexto. En pantalla significaba que los datos se eliminaron porque el terminal estaba en LOCAL. En impresora significaba que la impresión previa seguía en curso y la nueva petición fue eliminada. En copia de pantalla podía indicar que el dispositivo ya estaba imprimiendo. Un único contador de “ocupado” impediría reconstruir causa y pérdida.

LOCAL suspendía el descenso, no toda la estación

Antes de cambiar a LOCAL para pruebas o configuración, el cliente enviaba LOCAL-STATE. El servidor respondía y suspendía los flujos de pantalla e impresora hasta recibir ONLINE-STATE.

Si aun así llegaban datos del servidor, el cliente los borraba. La recepción TCP y el EOR podían ser impecables; la decisión local seguía siendo no aplicarlos. Sin embargo, mensajes enviados desde la pantalla cliente y movimientos de otras direcciones podían continuar. El control era direccional y selectivo.

Esta geometría importa durante una avería. “La sesión está viva” no demuestra que la pantalla acepte datos. “El terminal está local” no demuestra que todo tráfico se haya detenido. Cada afirmación necesita el flujo y el sentido que la hacen verdadera.

Copiar la pantalla abrió una segunda obligación

Como la impresora podía estar compartida con el servidor, el cliente no comenzaba una copia local por su cuenta. Enviaba COPY-REQ por la tercera dirección. Si el servidor autorizaba la acción, contestaba LOCAL-COPY.

Ese mensaje era respuesta y petición a la vez. Cerraba el permiso y abría la espera del resultado. El cliente debía informar después ACK, ERROR, BUSY, ABORTED, PURGED o NOT-AVAILABLE.

La autorización, el intento y el efecto permanecían separados. El servidor podía conceder uso del recurso compartido; el cliente podía ejecutar el flujo; el dispositivo podía producir o no una hoja. El artículo sobre RFC 1318 ya explica por qué señales físicas como PaperOut tampoco prueban una impresión. Aquí el asunto es anterior: quién abrió el trabajo y qué respuesta le pertenece.

La cancelación caducaba al emitirse la respuesta

Una indicación PURGE podía intentar abortar una petición que aún no había sido reconocida. Si lo lograba, la respuesta era PURGED. Si la respuesta ya había salido, la purga se borraba y se ignoraba.

El mensaje no tenía poder retroactivo. Conservaba el historial acordado y admitía que una acción que ya cruzó al dispositivo podía necesitar otra forma de reparación. La publicación de un verbo “purgar” no convertía al protocolo en dueño de todo efecto posterior.

La posterior idea de Running-Code Primacy ayuda a formular esta lectura, sin atribuírsela a la RFC: un documento especifica una transición, el código decide según su estado y la realidad física deja otro registro. Ninguna capa debe falsificar la siguiente.

Una especificación no es un censo

La RFC 1921 prueba el diseño descrito. RFC 1576 documenta las prácticas TN3270 y delimita un reportaje anterior, no una equivalencia. Las fuentes no demuestran cuántos sistemas ejecutaron TNVIP, si un producto concreto cumplía cada regla ni si hubo una incidencia real por la segunda petición.

Tampoco prueban identidad, autorización, visualización, aplicación hôte o papel entregado. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption aporta una prueba contemporánea: mantener en común solo lo necesario para validar el intercambio y dejar las decisiones futuras donde pueden observarse.

La pequeña arquitectura de TNVIP merece historia por esa precisión. Cuando faltaba un número de transacción, no improvisó certeza: limitó el estado, declaró la pérdida y obligó al error a guardar su turno.