Resumen

  • RFC 933 propuso OUTMRK, la opción Telnet 27, para que el servidor enviara una franja de seguridad una vez y el cliente la mantuviera fuera del área de la aplicación.
  • WILL y DO acordaban usar la opción; el contenido concreto aún podía recibir ACK o NAK, y el User-Telnet conservaba el control del diseño de pantalla.
  • La franja visible no probaba clasificación, habilitación, autorización, integridad criptográfica ni lo que terminó viendo la persona.

El problema de RFC 933, publicada por S. Silverman en enero de 1985, no comenzaba en una tabla de rutas ni en una contraseña. Comenzaba en el borde de una pantalla. Ciertos sistemas militares asociaban un nivel de seguridad a una conexión Telnet y necesitaban mostrar un aviso correspondiente.

La práctica disponible mezclaba ese aviso con los datos de cada pantalla. El servidor tenía que repetirlo y conocer el tamaño del equipo remoto. Una limpieza de pantalla podía arrastrar también la advertencia. OUTMRK propuso separar ambos planos: el servidor entregaría texto y posición; el Telnet del usuario reservaría el espacio y adaptaría allí la salida de la aplicación.

IANA aún registra el número 27 como Output Marking. Ese asiento evita que dos opciones reclamen el mismo código. No dice qué nivel es correcto ni demuestra que alguien implantó el mecanismo.

Entender una opción no era aceptar cualquier aviso

La RFC 854 daba a Telnet una negociación reversible. WILL OUTMRK ofrecía enviar información de marcado; DO OUTMRK aceptaba recibirla. WON'T y DON'T mantenían el rechazo como estado normal, y el intercambio de marcas estaba desactivado por defecto.

Superada esa etapa, el servidor enviaba IAC SB OUTMRK CNTL data IAC SE. CNTL indicaba ubicación y data contenía texto ASCII. Entonces llegaba una segunda decisión del cliente: ACK, ASCII 6, si el aviso era satisfactorio; NAK, ASCII 21, si objetaba.

RFC 933 no ordenaba una reacción universal al NAK. El servidor podía ensayar un texto más aceptable o actuar de otra manera, incluso terminar la conexión. Un rechazo era información para una política local, no la política completa.

La RFC 855 separaba expresamente el acuerdo para hablar de parámetros y la subnegociación de esos parámetros. Por eso DO OUTMRK, ACK y una decisión de acceso no deben aparecer como un mismo hecho en un registro.

ACK tampoco era una certificación. Solo decía que el User-Telnet aceptaba aquellos datos para realizar el marcado. No verificaba quién asignó el nivel, si el usuario podía consultar un objeto, si el canal estaba autenticado o si el monitor conservaría el aviso después de cambiar de tamaño.

El cliente pasó a custodiar una frontera móvil

Tras ACK, el cliente debía traducir los controles de cursor para que la aplicación utilizara únicamente su zona. Esa obligación convertía al terminal en un pequeño motor de composición: una región persistente para el marcado y otra para el trabajo remoto.

El indicador D dejaba la ubicación al cliente. T y B solicitaban arriba y abajo. L y R nombraban laterales cuya definición precisa el propio RFC dejó pendiente. La especificación podía asignar letras, pero no podía inventar una geometría común para dispositivos distintos.

CRLF separaba líneas. El ASCII Group Separator permitía reunir varias marcas en una sola subnegociación. En todos los casos, el receptor debía situarlas y evitar que la aplicación las invadiera.

De ahí nace una diferencia de evidencia. Una traza puede contener WILL, DO, el aviso y ACK de manera impecable. Minutos después, un redimensionamiento o una secuencia de borrado puede haber ocultado la franja. La aceptación en el cable y la persistencia visual necesitan pruebas diferentes.

El servidor podía finalizar el marcado con WON'T. El cliente podía iniciar la convención con DO y abandonarla con DON'T si el acuerdo no iba seguido de datos. El mecanismo contenía tanto un camino de rechazo como uno de retirada.

El texto representaba una regla; no la ejecutaba

RFC 933 citaba los criterios estadounidenses para sistemas confiables. La copia oficial preservada por NIST del DoD 5200.28-STD es de diciembre de 1985 y sustituyó a los criterios de 1983 mencionados por el RFC. Sirve como contexto limitado, no como prueba de que la opción cumpliera el sistema entero.

El documento coloca el marcado legible de la salida y el control de acceso obligatorio en apartados diferentes. La marca debe representar la sensibilidad y sus excepciones han de poder auditarse. Otra función decide qué sujetos acceden a qué objetos y dispositivos. La separación impide que una cabecera visible se convierta, por costumbre, en permiso.

OUTMRK no incorporaba firma, MAC, frescura, vinculación autenticada al canal ni catálogo de niveles. Los bytes correctos probaban una propuesta sintáctica. Para sostener la verdad de la marca hacían falta la autoridad que asignó el contexto, la asociación con la sesión y un cliente de confianza que preservara el área.

Una franja puede ser muy valiosa: avisa de un entorno inesperado y ayuda a no mezclar información. Su valor, sin embargo, depende de una cadena. Si se conserva solo el texto, se pierde la diferencia entre mostrar una política y hacerla cumplir.

Ahorrar repeticiones desplazó la obligación

El servidor ganó eficiencia al dejar de redibujar y medir pantallas remotas. El cliente heredó memoria, geometría, traducción de cursor, múltiples avisos, cambios de tamaño y respuestas ante datos inaceptables. El coste no desapareció: cambió de custodio.

Un buen registro distingue el contexto asignado, el texto generado, la negociación, el ACK/NAK, el estado de representación y las decisiones posteriores. Si solo anota «opción 27 activa», una barra de color puede acabar pareciendo más autorizada que el control que debería justificarla.

RFC 933 dejó así una lección de diseño: un sistema central puede pedir que una restricción humana persista en una superficie remota, pero no puede enviar también la autoridad en la misma cadena. El receptor custodia la presentación; el sistema de seguridad custodia la decisión.

Fuentes y límites

Las fuentes cerradas son RFC 933, RFC 854, RFC 855, el registro IANA de opciones Telnet y la copia oficial NIST de DoD 5200.28-STD. No prueban adopción, soporte moderno, conformidad de productos, una sesión clasificada real, visualización correcta, comprensión humana ni resultado operativo.