Resumen

  • RFC 1097 declaró en su propio cuerpo que especificaba un estándar. Hoy, el RFC Editor la registra con estado Unknown y en el Independent Stream; el Datatracker señala que no tiene rango formal en el proceso de estándares del IETF.
  • La opción ficticia no estaba activa por defecto. El cliente tenía que aceptar DO/WILL antes de recibir mensaje, duración y frecuencia. Ese acuerdo correspondía a dos extremos Telnet, no al consentimiento informado del usuario.
  • La obligación era intentar un renderizado dependiente de la implementación. Ni la subnegociación ni una llamada local demostraban que hubo imagen visible, percepción, persuasión o cambio de conducta.

Un texto no puede otorgarse el rango que invoca

La RFC 1097 presenta un encabezado familiar: Network Working Group, Request for Comments, autor B. Miller, CMU-NetDev y fecha de 1 de abril de 1989. Después afirma que «especifica un estándar» para la comunidad de Internet y asigna el número 257 a SUBLIMINAL-MESSAGE.

La frase prueba que el documento lo dijo. No prueba que la institución lo reconociera así. La ficha actual del RFC Editor muestra estado Unknown y stream independiente. La ficha del IETF Datatracker añade que la publicación no está avalada por el IETF y carece de rango formal en su proceso de estandarización.

No hay que borrar la contradicción; hay que conservar sus dos fuentes. El cuerpo es el objeto histórico. El catálogo es la superficie que clasifica ese objeto. Si el primero sustituyera al segundo, cualquier memorando podría convertirse en norma escribiendo la palabra adecuada en su portada.

El archivo también guarda piezas que no son reglas operativas

RFC 8700 describe los RFC del 1 de abril como una parte humorística singular del Independent Stream, sin el proceso formal ordinario de revisión y aprobación. Se seleccionan y revisan como piezas de ese género.

RFC 1097 hace humor con la precisión del formulario. Incluye significado de comandos, valor por defecto, motivación, notas de implementación y ejemplos. La estructura sería innecesaria si el lector no reconociera el modo de hablar de una especificación real. La serie preservó esa sátira; la preservación no convirtió su autodescripción en una decisión de estándares.

Hasta un canal subliminal empezaba apagado

La gramática procede del Telnet auténtico. RFC 854 define un transporte bidireccional orientado a bytes, un terminal virtual de base y opciones que cada extremo puede proponer, aceptar o rechazar. Un extremo que desconoce una opción puede negarse y conservar el estado NVT común.

RFC 855 exige dos fases cuando hay parámetros. Primero DO/WILL establece que las partes saben tratar la opción. Después llega la subnegociación. DON'T/WON'T permite abandonarla.

RFC 1097 conserva esas puertas. WILL pide permiso o confirma disposición para mostrar mensajes; WON'T se niega. DO pide al receptor que los muestre o le concede permiso; DON'T exige que no lo haga. El estado inicial es WON'T/DON'T, es decir, ningún mensaje.

La sátira imagina manipulación, pero no supone que el servidor ya sea dueño del terminal ajeno. Antes de enviar contenido debe obtener una capacidad del cliente. Ese límite técnico no equivale a una decisión humana, pero impide confundir propuesta con control adquirido.

El 257 estaba detrás de otra frontera

El número elegido queda fuera de la tabla ordinaria de un octeto. El registro actual de IANA enumera opciones hasta 255, donde aparece Extended-Options-List; no contiene una fila actual para 257 ni para SUBLIMINAL-MESSAGE.

RFC 861 había reservado precisamente 255 para EXOPL, un procedimiento capaz de abrir otras 256 opciones mediante una negociación encapsulada. RFC 1097 da el número 257, pero sus ejemplos utilizan la forma simbólica IAC DO/WILL/SB SUBLIMINAL-MESSAGE sin desarrollar el encuadre EXOPL.

La evidencia autoriza una observación modesta: el chiste se colocó al otro lado del espacio ordinario, junto a un mecanismo real de extensión. No autoriza a inventar una asignación IANA, una secuencia de bytes capturada o una implementación interoperable.

El cliente aceptó una función; nadie preguntó a la persona

Tras la negociación, el remitente podía fijar una duración de 16 bits en milisegundos, una frecuencia de 16 bits en segundos y una cadena. El cliente debía aceptar esos parámetros e intentar mostrar el texto de inmediato y a intervalos. La posición y el renderizado quedaban a criterio local. Los bytes con valor 255 debían duplicarse según las reglas Telnet.

Los ejemplos cambian «Use VMS» por «Go home» y terminan con duración y frecuencia cero más una cadena vacía. La motivación dice que los anuncios normales no convencían a ciertos usuarios de actualizar Telnet y cita REMOTE-FLOW-CONTROL. RFC 1080, publicada poco antes, había definido esa opción real con código 33 y una negociación previa propia.

Sin embargo, la palabra «acuerdo» de RFC 1097 nombra al cliente. No registra una explicación al usuario, una elección sobre el contenido ni permiso para influir en su atención. Un valor predeterminado o una decisión administrativa podía producir el WILL. Estado del protocolo y consentimiento humano no son sinónimos.

Además, la autoridad está repartida. El servidor elige texto y tiempo. El cliente controla cómo y dónde se intenta mostrar. La persona está fuera del intercambio. Atribuirle el sí del software borraría al actor que configuró realmente la opción.

El intento se quedaba varias pruebas antes del resultado

Recibir la subnegociación confirma parámetros en un flujo. Un registro local puede confirmar que una rutina de representación se ejecutó. Todavía faltaría observar el estado del terminal, la luz efectiva, la presencia de la persona, su mirada, su interpretación y cualquier conducta posterior.

El memorando afirma que una implementación de CMU calculaba tiempos según velocidad, vídeo y persistencia del fósforo, y que se desarrollaba otra para una luz Caps Lock en código morse. Al estar dentro de la pieza satírica, son afirmaciones del texto, no verificación independiente de que el software se distribuyó o funcionó.

La escala probatoria debe conservarse completa: texto archivado, clasificación oficial, capacidad negociada, parámetros recibidos, intento local, presentación física, percepción, persuasión y acción. Cada ascenso necesita una observación nueva.

Fuentes