Кратко

  • RFC 933 предложил опцию Telnet 27 OUTMRK: сервер один раз передаёт защитную надпись, а User-Telnet удерживает её вне области приложения.
  • WILL/DO означали согласие использовать опцию; конкретные данные всё ещё получали ACK или NAK, а компоновкой экрана управлял получатель.
  • ACK не доказывал правильность уровня, допуск пользователя, разрешение действия, криптографическую целостность или сохранность надписи на реальном дисплее.

RFC 933, опубликованный С. Сильверманом в январе 1985 года, начинался с края экрана. Некоторые военные системы связывали уровень безопасности с Telnet-соединением и должны были показывать соответствующую полосу. Тогда её включали в данные каждой страницы приложения.

Сервер повторял текст, знал размеры удалённого устройства и рисковал потерять отметку при очистке экрана. OUTMRK менял распределение труда: сервер отправлял текст и желаемое место, клиент резервировал область и направлял вывод приложения вокруг неё.

Реестр IANA Telnet Options по-прежнему связывает номер 27 с Output Marking. Это координация кода, а не подтверждение внедрения, истинности уровня или соответствия реализации.

Согласие на механизм не принимало любой текст

По RFC 854 WILL OUTMRK предлагал отправлять маркировку, DO OUTMRK — принимать её. WON'T и DON'T отказывали; обмен был выключен по умолчанию.

После согласия сервер посылал IAC SB OUTMRK CNTL data IAC SE: CNTL задавал положение, data содержал ASCII. Клиент отвечал ACK, ASCII 6, если данные его устраивали, или NAK, ASCII 21, если возражал.

После NAK сервер мог предложить более приемлемый текст либо принять другое решение, включая разрыв соединения. RFC не превращал отказ в универсальный приговор. ACK тоже был узким: клиент принимал данные для отображения, а не подтверждал полномочия.

RFC 855 отделял согласие обсуждать параметры от обмена параметрами в SB/SE. Поэтому DO, ACK надписи и разрешение команды — разные события.

Клиент хранил подвижную границу

После ACK User-Telnet должен был преобразовывать управление курсором, чтобы приложение оставалось в своей области. D оставлял размещение клиенту; T и B обозначали верх и низ. Для L и R RFC назвал стороны, но прямо не определил точный смысл.

CRLF разделял строки, ASCII Group Separator — несколько маркировок. Размещение оставалось задачей получателя. Изменение размера, очистка или ошибка эмулятора могли скрыть полосу после безупречного ACK. Сетевой факт и состояние дисплея требовали разных наблюдений.

Сервер прекращал режим через WON'T. Клиент мог запросить его командой DO и уйти через DON'T, если после договорённости данные не поступили. Отказ и завершение были штатными путями.

Надпись описывала правило, но не исполняла его

RFC 933 ссылался на американские критерии доверенных систем. Официально сохранённая NIST версия DoD 5200.28-STD вышла в декабре 1985 года и заменила редакцию 1983 года, упомянутую RFC. Это ограниченный контекст, не доказательство полной реализации критериев.

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

OUTMRK не задавал подпись, MAC, свежесть, аутентифицированную привязку канала или пространство имён уровней. Правильный синтаксис доказывал предложение текста. Истинность требовала источника классификации, связи с нужной сессией и доверенного пути отображения.

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

Экономия переносила хранение

Сервер переставал повторять надпись и угадывать высоту терминала. Клиент получал память, резерв области, преобразование курсора, несколько полос и изменения размера. Работа не исчезала.

Запись «опция 27 включена» теряет предложенный текст, ответ, положение, срок, источник уровня и последующее разрешение. Без них знакомая полоса начинает выглядеть более властной, чем контроль, на который она лишь указывает.

Источники и границы

Закрытый набор: RFC 933, RFC 854, RFC 855, IANA Telnet Options и архив NIST DoD 5200.28-STD. Они не доказывают внедрение, нынешнюю поддержку, соответствие продукта, реальную секретную сессию, корректный показ, понимание пользователем или результат работы.