Resumen

  • RFC 1408 publicó VAR=0 y VALUE=1 para la opción Telnet 36, mientras RFC 1571 documentó que la implementación BSD de referencia interpretaba ambos marcadores al revés.
  • RFC 1571 intentó reconocer cada linaje mediante formas ilegales, orden, recuentos y nombres conocidos. Algunas secuencias no bastaban y obligaban a asumir el orden del RFC.
  • RFC 1572 mantuvo el mapa escrito, pero lo puso bajo la nueva opción 39, NEW-ENVIRON. Decodificar una variable seguía sin obligar al servidor a aplicarla.

La opción coincidía; el diccionario no

RFC 1408 apareció en enero de 1993 con una tarea de coordinación: transportar información de entorno al abrir una conexión Telnet. La opción ENVIRON obtuvo el número 36. Dentro de su subnegociación, IS, SEND e INFO controlaban el intercambio; VAR, VALUE, ESC y USERVAR delimitaban nombres, valores y escapes. El documento asignó cero a VAR y uno a VALUE.

Un analizador necesitaba esas fronteras para distinguir tres estados: variable indefinida, variable definida sin contenido y variable con valor. Sin VALUE, el nombre quedaba indefinido; con VALUE seguido inmediatamente por otro tipo o por el final, existía con cadena vacía. Los bytes reservados podían aparecer como datos sólo si iban escapados.

La gramática parecía completa hasta que se comparó con el código que debía describir. RFC 1571 afirmó en 1994 que RFC 1408 había invertido las definiciones de VAR y VALUE respecto de BSD. El propio memorando calificó esa versión BSD como implementación de referencia y base de muchas otras.

No sabemos, por esas fuentes, cuántos equipos la ejecutaban ni cuánto tráfico atravesó el conflicto. Sí sabemos qué problema normativo existía: dos programas podían negociar la opción 36 y atribuir funciones opuestas a cero y uno. El registro simbólico no había borrado la memoria del software.

Un sobre para datos que Telnet no necesitaba entender

El propósito de ENVIRON no era convertir Telnet en un catálogo central de variables. Muchos sistemas querían llevar información de inicio a la máquina remota. Crear una opción nueva para cada necesidad habría obligado al protocolo a conocer detalles ajenos a la propia sesión. El diseño optó por un sobre genérico.

Los nombres conocidos eran USER, JOB, ACCT, PRINTER, SYSTEMTYPE y DISPLAY. USERVAR permitía pares arbitrarios proporcionados por el usuario. La etiqueta conservaba procedencia de clase, no confianza. RFC 1408 decía que una implementación cautelosa probablemente trataría ambos tipos con la misma desconfianza y no universalizaba la resolución de colisiones entre nombres.

La configuración predeterminada era no intercambiar nada: WONT ENVIRON y DONT ENVIRON. Un extremo ofrecía enviar mediante WILL; el otro autorizaba recibir mediante DO. Sólo quien había dicho DO podía iniciar SEND; sólo quien había dicho WILL podía contestar con IS o emitir un cambio posterior con INFO.

El protocolo separaba así capacidad de hecho. Consentir no era enviar. Solicitar no era obtener. IS debía responder al intercambio inicial, mientras INFO podía informar espontáneamente de cambios posteriores. Ninguno certificaba que el receptor hubiera modificado su estado.

El momento de llegada no cedía la decisión

La información solía ser útil al principio porque numerosos sistemas propagaban el entorno sólo al crear un proceso. El dato podía llegar antes del inicio de sesión y, por ello, cerca de una frontera delicada. RFC 1408 advirtió que aceptar una variable insegura en esa etapa podía permitir eludir o comprometer el programa de autenticación.

La advertencia no documentaba un ataque concreto. Identificaba una relación de poder: el cliente controlaba el contenido enviado, pero el servidor controlaba si ese contenido llegaba a una ruta privilegiada.

El receptor podía ignorar nombres desconocidos, preferir una fuente más precisa o utilizar un valor para elegir una cuenta sin copiarlo al entorno final. El ejemplo de TERM era inequívoco: si la opción Terminal-Type ya había determinado el tipo de terminal, el servidor podía descartar USERVAR TERM=xterm. Para un conflicto entre DISPLAY y la opción X-Display-Location, el RFC propuso usar la información recibida más recientemente.

Son políticas locales, no títulos de autoridad global. USER describía la cuenta que el cliente deseaba, no una persona autenticada. PRINTER no probaba que una impresora existiera ni que aceptara un trabajo. DISPLAY no demostraba una conexión ni una imagen visible. El sobre llevaba una afirmación hasta el punto de decisión; no decidía por él.

La incompatibilidad convirtió la sintaxis en evidencia

RFC 1571 diseñó una forma de reconocer el diccionario del otro extremo sin un campo explícito de versión. Para un cliente, SEND ofrecía una pista contundente: legalmente sólo debía contener VAR y USERVAR. Si aparecía el marcador que el lector entendía como VALUE, el servidor probablemente usaba los significados invertidos. El cliente debía invertir desde allí tanto el resto del análisis como la respuesta.

Si en SEND no aparecía cero ni uno, no había nada que observar. La instrucción era suponer las definiciones publicadas. Ese caso muestra que la ausencia de contradicción no equivalía a una identificación positiva.

El servidor analizaba mensajes IS o INFO, donde los valores sí eran legales. Un primer VAR sugería el orden del RFC; un primer VALUE, el orden BSD. Si comenzaba con USERVAR, había que escanear pares consecutivos, marcadores vacíos, cantidades relativas y cadenas que parecieran nombres conocidos. Algunas formas eran imposibles bajo un diccionario y, por tanto, discriminaban; otras sólo inclinaban la probabilidad.

Cuando todas las pruebas fallaban, la decisión predeterminada era asumir el RFC. La heurística no se convertía por ello en un hecho del emisor. Era una elección operativa reproducible sólo si se conservaban el flujo bruto, el número de opción, el contexto de negociación, la versión del analizador, la regla activada y la ambigüedad que quedaba.

El acuerdo nuevo necesitó un nombre nuevo

En enero de 1994, RFC 1572 no intentó obligar a la opción 36 a olvidar su historia. Conservó la definición escrita VAR=0, VALUE=1, pero la trasladó a la opción 39, llamada NEW-ENVIRON. Su explicación fue directa: un número nuevo permitía que las implementaciones del nuevo memorando interoperaran sin ambigüedad.

El cambio de número resolvía algo que una fe de erratas no podía resolver. Un documento actualizado podía declarar un significado; no podía revelar qué binario antiguo se encontraba al otro lado. Negociar 39 sí seleccionaba una gramática cuyo punto de partida era compartido.

El registro IANA de opciones Telnet conserva ambas entradas: 36, Environment Option, remite a RFC 1408; 39, New Environment Option, a RFC 1572. El registro hace visible la bifurcación. No afirma que un host implemente ninguna, ni que haya aceptado variables o creado un proceso.

La solución tampoco engordó el centro común. NEW-ENVIRON mantuvo la negativa predeterminada, el consentimiento por dirección y la libertad del receptor para aplicar su propia validación. La red acordaba cómo leer; cada extremo seguía decidiendo qué hacer.

De la tabla al resultado había varios propietarios

Una prueba completa debía distinguir la asignación publicada, el byte emitido, el diccionario del emisor, la lectura del receptor, la inferencia heurística, el par candidato, su clase de procedencia, la política local, la creación de proceso y el efecto de aplicación. Saltar de la primera capa a la última convertía documentación en resultado.

Publicar RFC 1408 no reprogramó BSD. Negociar WILL no probó un IS. Decodificar USER no autenticó una identidad. Aceptar una variable no probó que el proceso la heredara. Heredarla no probó que una orden se ejecutara. Cada transición necesitaba su propio registro.

Fuentes

Las fuentes demuestran la gramática, el relato contemporáneo del conflicto BSD, las heurísticas, el número nuevo y el registro. No demuestran una implementación concreta, prevalencia, ataque, identidad, autenticación aceptada, entorno aplicado, orden ejecutada ni riesgo actual.