Кратко

  • RFC 1096 закрепил за X-DISPLAY-LOCATION номер Telnet-опции 35. WILL и DO лишь разрешали последующее обсуждение; само значение передавалось только в ответе IS на запрос SEND.
  • Строка имела Unix-форму DISPLAY <host>:<dispnum>[.<screennum>]. Клиент Telnet должен был преобразовать локальное сокращение вроде :0, но такое преобразование не подтверждало имя, владельца или сетевую доступность.
  • Удалённое приложение всё равно устанавливало отдельное X-соединение и проходило контроль доступа и авторизацию X-сервера. Получение адреса, успешный setup и появление окна у пользователя были разными фактами.

Удалённому процессу не хватало локальной координаты

Пользователь запускал Telnet-клиент в среде X, подключался к другой машине и выполнял там графическое приложение. Процесс находился на удалённом хосте, а вывод должен был вернуться на рабочую станцию пользователя. Переменная DISPLAY, естественная для локальной среды, могла быть неизвестна удалённому shell.

RFC 1096, опубликованный в марте 1989 года как Proposed Standard, назначил X Display Location код 35. Telnet-сервер получил возможность запросить у клиента местоположение X-дисплея, под которым тот работал. Современный реестр Telnet Options IANA по-прежнему связывает 35 с RFC 1096.

Через Telnet не шли графика и запросы X. По существующему каналу доставлялась координата, после чего другой протокол мог попытаться открыть собственный канал. Видимая цельность интерфейса скрывала шов между системами.

WILL и DO разрешали только разговор

Исходное состояние — WON’T/DON’T: вход в систему сам по себе не раскрывает адрес экрана. В терминах RFC 854 WILL означает готовность выполнять опцию, DO — просьбу или подтверждение её выполнения другой стороной. Для опции 35 речь идёт о готовности позже отправить либо принять адрес.

RFC 1096 прямо ограничивает смысл команд разрешением на будущее обсуждение. RFC 855 делит подпереговоры на два этапа: сначала стороны соглашаются обсуждать параметр, затем передают его между SB и SE. WON’T и DON’T могут прекратить дальнейший обмен.

Положительный результат доказывает состояние двух Telnet-участников. Он не удостоверяет будущую строку, не подтверждает пользователя и не спрашивает X-сервер о политике. Разрешение узнать адрес не является разрешением воспользоваться ресурсом.

SEND и IS задавали направление

Только отправитель DO вправе послать SEND; только отправитель WILL вправе ответить IS. Самопроизвольная передача местоположения запрещена. Общая готовность и фактическое раскрытие остаются отдельными событиями.

Последовательность заимствована у RFC 1079, Telnet Terminal Speed Option. RFC 1096 использовал знакомую модель запрошенной строки состояния. Это упрощало реализацию, но не уравнивало содержание: скорость относится к терминалу, а X-адрес указывает на самостоятельный сервис.

В примере IS содержит NVT ASCII SRI-NIC.ARPA:0.0; вся подкоманда занимает 22 октета. Получатель знает, что Telnet-партнёр сообщил именно эту строку. Никакого наблюдения X-соединения ещё не было.

Переписывание :0 меняло область смысла

Unix-синтаксис DISPLAY выглядит как <host>:<dispnum>[.<screennum>], без пробелов и лишних символов. На локальной машине :0 или unix:0.0 достаточно: хост подразумевается. Если передать сокращение без изменения, удалённая машина поймёт «локальный» как саму себя.

Поэтому RFC 1096 требует от Telnet-клиента подходящим образом изменить значение до отправки. Клиент разворачивает неявный контекст в удалённо понятный адрес. Документ не утверждает, что при этом проверяются подлинность имени, DNS, маршрут, порт или принадлежность дисплея пользователю.

Правильная строка может быть устаревшей. Точный адрес может быть недоступен. Доступный сервер может отклонить клиента. Синтаксис, сеть и полномочия требуют собственных доказательств.

X начинал отдельное соединение

RFC 1013 описывает X-клиента, устанавливающего самостоятельное IPC-соединение с X-сервером. Для TCP дисплею N соответствует порт 6000+N. Полученные host и номер помогают выбрать назначение.

Поток Telnet не превращается в поток X. Опция 35 не является туннелем, прокси или перенаправлением и не переносит графические запросы. Удалённое приложение начинает новый путь, где отдельно действуют разрешение имени, маршрутизация, фильтры и состояние listener.

Граница важна для диагностики. Полученный IS доказывает доставку адреса. Ошибка TCP возникает на последующей сетевой ступени. Отказ setup принадлежит X. Общая фраза «сломался Telnet» стирает причинную информацию.

Дверь оставалась у X-сервера

Setup X содержит имя протокола авторизации и авторизационные данные, а также версию и порядок байтов. Сервер может отказать с объяснением либо принять соединение и вернуть сведения об экранах, форматах и ресурсах. Выбор допустимого механизма авторизации вынесен за пределы ядра протокола.

RFC 1013 отдельно задаёт список контроля доступа по хостам. X-сервер способен отклонить соединение по собственным правилам. Решения WILL/DO этих правил не заменяют.

В нынешнем реестре IANA X Display Location имеет номер 35, а Telnet Authentication — отдельный номер 37. Текущая классификация не позволяет назвать 35 аутентификацией, но не доказывает применение более поздней опции в установках 1989 года.

Лестница свидетельств последовательна: WILL/DO разрешает подпереговоры; SEND/IS доставляет строку; TCP подтверждает путь до endpoint; принятый X setup подтверждает допуск соединения. Ни одна ступень не показывает, что приложение создало требуемое окно.

Результат для человека оставался последней проверкой

После setup приложение должно создать ресурсы, послать запросы и отобразить окно. Сервер должен обработать их, а окно — остаться доступным на нужном экране. Пользователь должен его действительно увидеть. Принятие соединения всего этого не заключает.

RFC 1096 ценен точностью границ. Он решает передачу контекста, не приписывая себе шифрование, аутентификацию, политику доступа, пересылку графики или результат приложения. Более позднее утверждение требует более позднего наблюдения.

Запись IANA также не служит переписью внедрения. Она подтверждает номер и ссылку, но не распространённость, политику конкретного хоста или опыт пользователя. Источники позволяют описать механизм, а не выдумать его рыночную судьбу.

Адрес пересёк Telnet. Решение о доступе осталось за X.

Источники