Resumen

  • El Telnet de 1972 reservaba 128–255 para control. El diseño posterior concentró la autoridad en IAC, valor 255, y permitió que los otros 255 valores no chocaran con órdenes aisladas.
  • Un 255 literal se codifica como IAC IAC. Binary Transmission habilita los ocho bits, pero no vuelve opaco el flujo: el receptor sigue buscando IAC y ejecutando órdenes integradas.

Dos apariciones en el cable se convertían en un dato

Un archivo binario contiene 255. Para el parser Telnet, el mismo valor anuncia que el byte siguiente es una orden. Si siempre lo interpreta como control, corrompe el archivo; si siempre lo interpreta como dato, ignora instrucciones reales.

La gramática compartida resuelve el conflicto. IAC abre control. IAC más un código definido invoca una orden y quizá espera más octetos. IAC más IAC entrega un solo 255 a la aplicación. El emisor añade una copia de encuadre y el receptor la retira.

No es una comilla genérica que vuelva literal cualquier valor siguiente. Solo el segundo IAC tiene ese significado. Los demás valores continúan formando sintaxis Telnet. El precio de un byte especial recuperó casi todo el alfabeto y mantuvo datos y órdenes dentro del mismo orden TCP.

El primer Telnet había ocupado media tabla

RFC 318, de abril de 1972, asignaba 0–127 a USASCII y 128–255 a señales especiales. Era cómodo para terminales de texto distintos, pero hacía difícil transportar juegos mayores o binario: media tabla no podía ser dato corriente.

El RFC mencionaba escapes a otros códigos, incluido un modo Transparent, y admitía que el significado de las señales o el regreso a ASCII podía quedar indefinido. Ampliar el vocabulario de datos chocaba con autoridad ya pegada a valores desnudos.

RFC 435, discusión de 1973, imaginó un carácter QUOTE que obligaría a tratar el siguiente byte como dato. No era todavía IAC, pero formuló la presión: el límite de control debía sobrevivir al cambio de modo.

Un prefijo concentró la autoridad

RFC 764, de 1980, describió una conexión TCP orientada a bytes de ocho bits con información Telnet intercalada. RFC 854, estándar base de 1983, conservó la arquitectura.

Toda orden empieza con IAC, 255. WILL, WON’T, DO y DON’T añaden el número de opción; otros códigos significan fin de subnegociación, no operación, interrupción y funciones básicas.

La justificación es explícita: al crecer el uso del espacio de datos, había que minimizar colisiones. Solo IAC se duplica cuando es dato; los otros 255 valores no son confundidos con órdenes Telnet por su número. “Transparente” no elimina convenciones NVT; limita qué valores desnudos poseen autoridad de comando.

El lugar de la orden marcaba el nuevo régimen

RFC 854 exige insertar una orden que cambie el tratamiento de los datos en el punto donde debe empezar la nueva interpretación. El control no viaja aparte; queda entre los últimos bytes del régimen anterior y los primeros del siguiente.

Por eso el parser conserva estado. TCP puede entregar IAC ahora y su continuación después; sus segmentos no son registros Telnet. Decodificar dos veces también es peligroso: dejar ambos IAC agrega un byte, y plegar una orden como si fuera el par elimina control.

TCP mantiene el orden y Telnet define la gramática. Ninguno fabrica mensajes por sí solo.

La subnegociación heredó el escape

RFC 855 encierra parámetros entre IAC SB y IAC SE. Un receptor que no conoce la opción todavía puede hallar el final. Si un parámetro contiene 255, debe duplicarlo.

La opción gobierna el significado interno, pero Telnet conserva el encuadre. Sin la duplicación, datos opacos podrían parecer una nueva orden o un final falso. La disciplina permite atravesar extensiones desconocidas sin perder el lugar del flujo.

Binary abrió ocho bits y mantuvo IAC

RFC 856 define Binary Transmission como opción 0 y se negocia por separado en cada dirección. Activa, todo byte no precedido por IAC se interpreta como dato de ocho bits. IAC IAC sigue significando el dato 255 y una orden IAC efectiva sigue siendo orden.

Binary no es “TCP crudo”. Quita transformaciones textuales, no la frontera del protocolo. En 1989, RFC 1123 lo convirtió en obligación: aun en Binary hay que escanear IAC, obedecer órdenes y duplicar el 255 literal; dejan de hacerse conversiones CR, no el parsing.

El registro IANA de opciones Telnet conserva el espacio de opciones, incluida Binary 0. No es un censo de uso. También muestra por qué hay que separar ámbitos: la opción 255 no es el IAC 255 del flujo. La misma cifra no unifica funciones.

La repetición preservó una conversación ordenada

La aplicación elige datos. El emisor Telnet codifica 255 para que no adquiera poder por accidente. El receptor decide si ve una pareja o una instrucción. Las opciones pueden cambiar eco, terminal o modo, pero no apropiarse silenciosamente de IAC.

El coste es permanente: inspección de cada byte, un octeto extra por 255 literal, estado ante prefijos incompletos y posible desincronización tras un error. La ganancia también: datos y control evolucionan juntos sin confundir valor con autoridad.

El byte no se repetía para producir dos datos. La primera aparición entregaba su significado de comando para que la segunda pudiera seguir siendo uno.

Fuentes y límites

El reparto original procede de RFC 318, la propuesta QUOTE de RFC 435. RFC 764 y RFC 854 dan flujo e IAC; RFC 855 subnegociación; RFC 856 Binary; RFC 1123 requisitos, y IANA el registro. No demuestran despliegue presente, conformidad de productos, seguridad de parser, cifrado o autenticación.