Кратко

  • RFC 2066 требовал ACCEPTED, даже если получатель уже работал в предложенной кодировке: молчание больше не означало успех.
  • Одновременные CHARSET REQUEST разрешались по ролям: сервер отклонял запрос клиента, а клиент отвечал на запрос сервера.
  • Ответ подтверждал получение и выбор набора для следующего текста, но не правильность байтов, таблицы, обработки приложением, идентичность сторон или безопасность канала.

Представим, что сторона Telnet перечислила два набора символов и не получила ответа. Возможно, партнёр уже применяет один из них и считает молчание правильным. Возможно, запрос потерян. Возможно, подпротокол реализован неверно. Для отправителя все три случая оставляют одинаковую запись: ничего.

Опубликованный в январе 1997 года экспериментальный RFC 2066 не позволил этой неоднозначности стать общим состоянием. Он определил опцию Telnet 42, CHARSET, для явного выбора кодировки текста и необязательной передачи таблиц преобразования. Главным оказался не перечень алфавитов, а требование завершать переход наблюдаемым ответом.

Базового запрета на циклы оказалось недостаточно

RFC 854 построил опции Telnet на DO, DON'T, WILL и WON'T. Симметрия позволяла двум одновременным просьбам служить положительными ответами друг другу. Она же могла создать бесконечный обмен подтверждениями. Поэтому просьбу о действующем режиме не следовало подтверждать, а запрос изменения требовал ответа, даже если режим в итоге не менялся.

RFC 855 отделил согласие обсуждать опцию от передачи параметров. Сначала стороны договаривались через DO/WILL, затем обменивались значениями между IAC SB и IAC SE. DO CHARSET и WILL CHARSET разрешали разговор, но ещё не задавали трактовку следующего байта текста.

RFC 2066 запретил переносить молчание на запрос набора символов. Если получатель уже отправлял и ожидал текст в одном из перечисленных наборов, он всё равно должен был ответить ACCEPTED. Причина названа прямо: определённость. Инициатор не должен ждать и выводить ответ из истечения времени. Положительная квитанция сама не подтверждалась, поэтому новый цикл не возникал.

Упорядоченный список оставался предложением

Посылать CHARSET REQUEST могла сторона, уже получившая DO CHARSET и отправившая WILL CHARSET, в любом порядке. Она перечисляла один или несколько наборов по предпочтению. Имя без частного префикса X- должно было быть зарегистрировано IANA. Получатель сохранял собственное решение о возможностях и предпочтении.

Обмен имел четыре выхода: подтвердить уже используемый набор; выбрать другой поддерживаемый; отправить таблицу, если она была предложена; либо вернуть REJECTED, когда ни один вариант не подходил. Положительный ответ называл элемент исходного списка. Отрицательный подтверждал получение, но отклонял весь список в этой итерации.

ACCEPTED и REJECTED завершали текущую подпереговорную процедуру. Первый задавал кодировку последующего текста, второй не давал предложениям вступить в силу. Ни один не был диагнозом всей реализации и не запрещал будущий новый запрос.

Для двух запросов требовалась назначенная уступающая сторона

Когда оба допущенных участника посылали CHARSET REQUEST до получения встречного, симметрия останавливала процесс. Новый запрос не считался ответом на незавершённый. Каждая сторона могла ждать завершения собственной инициативы, одновременно удерживая чужую.

RFC 2066 разорвал симметрию ролями. Сервер обязан был отрицательно ответить на запрос клиента, а клиент — обработать запрос сервера. Одна инициатива закрывалась, вторая могла прийти к ACCEPTED, REJECTED или таблице. Это не утверждение превосходства серверного предпочтения, а общий способ вычислить следующий шаг из стабильных ролей.

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

Ответ разделял поток байтов

После ACCEPTED дальнейший текст должен был использовать выбранный набор. Пока согласование не завершилось, данные следовало поставить в очередь. Квитанция становилась границей между байтами старого и нового соглашения.

Действие было узким. Преобразование касалось текста, не команд Telnet, и работало только в режиме BINARY. Иначе предполагался NVT ASCII. Для блочных терминалов RFC советовал End of Record, чтобы сохранять границы записей. Выбор кодировки не отменял окружающих правил.

Таблицы имели отдельные завершения: TTABLE-ACK подтверждал получение, TTABLE-NAK просил повтор, а многократная неудача должна была закончиться TTABLE-REJECTED или CHARSET REJECTED, не бесконечными пересылками.

Сила квитанции — в ограниченности её утверждения

Записанный ACCEPTED доказывает, что партнёр получил конкретный запрос и выбрал из него имя для последующего текста. Он не доказывает правильность дальнейших байтов, таблицы, декодирования или пользовательского результата. REJECTED подтверждает получение и отказ именно этого раунда, а не вечную неспособность.

Безопасность также не следует из выбора. В Security Considerations сказано лишь, что вопросы безопасности не обсуждаются. Согласование кодировки не аутентифицирует стороны, не даёт разрешений, не шифрует и не защищает целостность.

IANA по-прежнему указывает CHARSET под номером 42, а RFC имеет статус Experimental. Это свидетельство документа и назначения, не внедрения. Через более позднюю модель Lu Heng о минимальной начальной спецификации механизм можно прочесть как тонкий общий слой: условия запроса, конечные ответы, граница байтов и локально применимое правило конфликта. Это редакционная интерпретация, не доказательство замысла автора. Надёжный исторический вывод уже: если молчание имеет несколько смыслов, недостающую квитанцию нужно сделать частью протокола.

Источники