Кратко

  • Декабрьский RFC 884 1983 года закрепил за опцией Telnet TERMINAL-TYPE номер 24. Команды DO и WILL открывали обмен; SEND запрашивала название, IS доставляла его.
  • Терминал мог сперва назвать точную модель, затем более общее обозначение. Повтор последнего имени завершал список. В 1985 году RFC 930 устранил путаницу встречных сообщений, потребовав отправлять IS только в ответ на SEND.

Представьте программиста, который гордится аккуратной экранной формой. Пользователь подключается из другого города — и форма превращается в россыпь символов. Сеть передала байты честно; удалённый компьютер просто не знал, какие команды поймёт устройство на столе пользователя. Один терминал умеет передвигать курсор определённой последовательностью, другой ждёт другой. Бумажный телетайп вообще не мечтает о цветном меню.

У базового Telnet был общий язык для начала беседы — сетевой виртуальный терминал. Эта воображаемая машина позволяла не изучать каждую клавиатуру и каждый экран заранее. Когда программе хотелось большего, требовалось выяснить особенности реального устройства. Marvin Solomon и Edward Wimmers посвятили RFC 884 этому знакомству.

Новая опция получила номер 24. Исходные состояния DON'T и WON'T оставляли тип терминала за кадром. Сервер мог послать DO, другая сторона — согласиться с WILL. Разрешение получено, но имя ещё не названо. Затем сервер отправлял подкоманду SEND, код 1; ответ IS, код 0, содержал строку NVT ASCII. В примере документа терминал представлялся как IBM-3278-2. Регистр букв при сравнении имён значения не имел.

Список рекомендованных названий похож на экскурсию по вычислительному центру: дисплеи IBM, устройства из среды TOPS20, терминалы Unix. Там стоят рядом DEC-VT100 и TELETYPE-33. В этом соседстве виден смысл опции. Единая сеть связывала устройства, которые могли по-разному понимать даже самые простые замыслы экранного интерфейса. Полученное имя можно было передать локальному драйверу и при подходящей реализации выбрать команды для курсора или цвета, иногда в связке с опцией BINARY.

Самая занятная проблема была лингвистической. Авторы сравнили написания IBM3278-2 и IBM-3278/2: обе стороны могут думать об одном устройстве и всё равно не узнать друг друга. Специального отрицательного ответа на непонятное имя протокол не давал. Поэтому терминал, у которого есть точное и более широкое обозначение, мог выдавать их по очереди при повторных запросах SEND. Сначала точное, затем обобщённое. Когда имена заканчивались, терминал повторял последнее. Два одинаковых ответа подряд означали: хватит расспросов. Машины получили сетевой эквивалент фразы «Может быть, вас знают под другим именем?»

Если полезного имени не находилось, существовал ответ UNKNOWN. Понятное название давало серверу материал для решения, а само решение оставалось за программой. Она могла выбрать подходящую обработку вывода или отказаться от связанной возможности, если название не распознавала. Обмен именами и отображение символов были двумя последовательными действиями.

Первоначальный порядок разговора оставлял место для перебивания. По RFC 884, после DO и WILL сторона терминала могла отправить IS, не дожидаясь вопроса. Авторы ожидали лишь дублирования ответа при одновременном SEND. Январский RFC 930 1985 года поправил правило: спонтанное сообщение и запрос могли разойтись навстречу друг другу, после чего следующий ответ становился двусмысленным — ответ на вопрос или второе имя? С тех пор IS должен следовать за SEND.

В 1989 году RFC 1091 расширил механизм: клиент получил возможность перечислять несколько режимов эмуляции и переключаться между ними по запросу сервера. Документ 1983 года решал более приземлённую задачу. Компьютер хотел правильно обращаться с чужим экраном. Сначала он спрашивал имя, затем при необходимости просил назвать другое.