Resumen

  • RFC 1096 asignó la opción Telnet 35 a X-DISPLAY-LOCATION. WILL y DO solo permitían hablar después de la opción; SEND e IS realizaban el intercambio solicitado de la ubicación.
  • La cadena seguía <host>:<dispnum>[.<screennum>]. El cliente debía transformar atajos locales como :0 antes de enviarlos al servidor remoto, pero esa transformación no validaba identidad, propiedad ni alcance de red.
  • La aplicación remota abría una conexión X independiente y afrontaba el control de acceso y la autorización del servidor X. Recibir IS no probaba acceso, y aceptar el setup tampoco probaba que el usuario viera la ventana.

Una dirección debía viajar en sentido contrario al comando

La sesión Telnet llevaba las pulsaciones del usuario a una máquina remota. Si allí se iniciaba una aplicación X, sus gráficos debían regresar a la estación local. Al proceso remoto le faltaba un dato que el entorno local solía dar por supuesto: la ubicación del display.

La RFC 1096, publicada en marzo de 1989 como Proposed Standard, definió la opción 35 para que el host Telnet remoto pudiera pedir ese dato. El registro IANA de opciones Telnet aún conserva el número y la referencia.

La opción no transportaba la interfaz X. Su aportación era más pequeña: enviar una coordenada por una conexión existente para que otra conexión pudiera intentarse después. El comando y el dibujo cruzaban la red por caminos separados.

Negociar no era abrir la pantalla

El estado inicial es WON’T/DON’T. Según la RFC 854, WILL declara disposición a realizar una opción y DO pide o confirma que el otro lado la realice. En RFC 1096, WILL significa disposición a suministrar más tarde la ubicación; DO, disposición a recibirla.

El texto limita expresamente ese acuerdo: sirve para obtener y conceder permiso para una conversación futura. La RFC 855 separa las dos fases de toda subnegociación: primero se acepta tratar el parámetro y luego se transmite entre SB y SE. WON’T o DON’T pueden revocar la posibilidad de continuar.

Por tanto, el éxito de WILL/DO describe el estado de dos pares Telnet. No autentica el nombre que aparecerá después ni consulta la política X. Poder preguntar por una puerta no equivale a tener la llave.

La ubicación solo podía responder a SEND

El emisor de DO es el único autorizado a mandar SEND. El emisor de WILL es el único que puede contestar IS. La ubicación no debe enviarse de forma espontánea. Este reparto evita que un acuerdo general se confunda con la entrega efectiva de un valor.

La RFC 1079, dedicada a la velocidad de terminal, usa el mismo esquema. RFC 1096 lo adoptó casi literalmente. Era una forma económica de estandarizar estados solicitados, aunque el contenido cambiara de significado. Una velocidad no dirige hacia otro servicio; una ubicación X sí.

El ejemplo SRI-NIC.ARPA:0.0 muestra un valor NVT ASCII y una suborden de 22 octetos. Al recibirlo, el servidor sabe que el par declaró esa cadena conforme al formato. Todavía no sabe si una conexión X llegará a destino.

:0 necesitaba dejar de significar «esta máquina»

La gramática Unix DISPLAY es <host>:<dispnum>[.<screennum>], sin espacios ni adornos. Un programa local puede usar :0 o unix:0.0 porque su máquina está implícita. Para un proceso remoto, esa elipsis señalaría su propia máquina, no el escritorio del usuario. RFC 1096 obliga al cliente Telnet a modificarla antes de transmitirla.

Esa modificación cambia el ámbito del localizador. Hace explícito un host que el contexto local permitía omitir. No certifica el nombre, no verifica DNS, no prueba una ruta y no demuestra que la persona sea dueña del display.

El valor puede estar bien escrito y ser obsoleto. Puede ser correcto y no alcanzable. Puede ser alcanzable y estar protegido. Cada adjetivo necesita una observación distinta.

X conservó una conexión propia

La RFC 1013 presenta al cliente X con una conexión IPC independiente al servidor. En TCP, el display N escucha en el puerto 6000+N. La cadena de RFC 1096 ayuda a seleccionar host y número; no realiza el establecimiento.

La sesión Telnet no se convierte en la sesión X. La opción 35 no es túnel, proxy ni reenvío, y no lleva solicitudes gráficas. Tras recibir IS, la aplicación remota debe iniciar otro trayecto, sometido a resolución, rutas, filtros y estado del listener.

Separar los caminos mejora el diagnóstico. IS recibido prueba la entrega del localizador. Un rechazo TCP pertenece a la etapa de red. Una negativa del setup pertenece a X. Una etiqueta única como «falló Telnet» perdería precisamente la información causal.

El servidor X seguía decidiendo

El setup de X incluye nombre y datos de un protocolo de autorización. El servidor puede devolver un motivo de fallo o aceptar y ofrecer información de formatos, pantallas y recursos. RFC 1013 deja fuera del núcleo la selección del mecanismo de autorización válido.

También define una lista de control de acceso de hosts. La aceptación depende así de controles propios del servidor X. Ninguna decisión DO/WILL puede sustituirlos.

El registro IANA actual coloca X Display Location en 35 y Telnet Authentication en 37. Esa separación ayuda a clasificar el localizador: no era un mecanismo de autenticación. Sin embargo, no autoriza a proyectar la opción 37 o una configuración moderna sobre sistemas de 1989.

La escalera probatoria queda clara. Negociación significa permiso para subnegociar. IS significa localizador recibido. Conexión TCP significa camino hasta un servicio. Setup aceptado significa admisión X bajo sus controles. Todavía falta observar que la aplicación creó la ventana correcta y que el usuario obtuvo el resultado.

El último veredicto estaba en la pantalla

Después del setup, el programa debe crear recursos, enviar operaciones, mapear una ventana y mantenerla utilizable. La pantalla puede ser incorrecta, la ventana puede no llegar a mostrarse o el usuario puede no verla. La admisión de una conexión no contiene esas conclusiones.

Esta modestia hace valiosa a RFC 1096. Resolvió la transmisión de contexto sin fingir que también resolvía verdad del nombre, conectividad, autenticación, autorización, aplicación y experiencia humana. Cuando cada contrato es estrecho, cada fallo puede atribuirse.

Tampoco la permanencia en IANA prueba adopción. Un registro muestra una asignación, no cuántos equipos la usaron ni qué ocurrió en un host concreto. Las fuentes oficiales permiten afirmar el mecanismo y sus límites, no inventar un desenlace de mercado.

La historia cabe en una frase que conserva las capas: la ubicación atravesó Telnet; la autoridad nunca salió de X.

Fuentes