Кратко

  • RFC 2122 задавал URL интерактивной мультимедийной службы, а не объекта данных; клиент VEMMI обычно поддерживал непрерывный TCP-сеанс на порту 575.
  • URL мог выбрать службу и передать именованные параметры, но не имя пользователя и пароль. Поддержка схемы, проверка личности и VEMMI_Open оставались отдельными стадиями.
  • application/vemmi относился к отдельной доставке объектов. Оперативные объекты могли быть программами, поэтому получение, согласие, запуск и безопасный итог требовали разных доказательств.

Адрес службы

RFC 2122, опубликованный в марте 1997 года как Proposed Standard, определил схему VEMMI — расширенного человеко-машинного интерфейса для видеотекса и мультимедийного поиска. Документ прямо говорит: URL обозначает не объект данных, а интерактивную службу.

Форма vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value> могла включать узел, порт, службу и пары атрибут—значение. По умолчанию использовался порт 575; клиент мог проигнорировать иной порт из URL ради безопасности. Эти поля описывали попытку запуска, но не доказывали DNS, слушающий процесс, наличие службы или принятие параметров.

Обычно VEMMI сохранял TCP/IP-соединение на весь сеанс. Через него система управляла объектами и передавала действия пользователя. Web был местом встречи, а не самой средой исполнения.

Диалог начинался после щелчка

Сервер мог запросить service:, username: и password:. Клиент отвечал значением из URL или конфигурации либо спрашивал пользователя. До VEMMI_Open терминал оставался в стандартном режиме, совместимом с видеотексом или telnet.

Имя и пароль запрещалось помещать в URL: выбор службы не был идентификацией. Примеры 200 OK и 401 Unauthorized показывали ветви протокола, а не реальные измерения. Ссылка, обработчик, TCP, принятая личность и открытый сеанс — разные квитанции.

Неизвестная схема могла не дойти до VEMMI

Поддержка могла быть встроенной или обеспечиваться внешней программой. Без неё один браузер отвергал неизвестную схему, другой ошибочно трактовал её как относительный URL и посылал HTTP-серверу страницы запрос к несуществующему пути. Само наличие vemmi:// в HTML не доказывало даже локальный обработчик.

RFC предлагал отдельную загрузку клиента, распознавание ошибочного запроса и проверку Accept: application/vemmi. Он не измерял распространённость этих решений. Нормативный механизм нельзя превращать в статистику внедрения.

Объект шёл другим путём

application/vemmi позволял передавать объекты через HTTP, почту и иные каналы без непрерывного сеанса. Такой файл мог даже содержать URL для последующего запуска. Схема именовала путь к службе; медиатип описывал объект для перевозки и декодирования.

IANA и сегодня содержит постоянную схему vemmi, медиатип application/vemmi и порт 575. Это состояние реестров, не телеметрия. Оно не доказывает поддержку программ, активную службу, трафик, совместимость или применение.

Выполнение требовало собственного разрешения

Объекты метакода могли нести команды, а оперативные объекты — исполняемые программы для клиента. RFC настоятельно советовал отключить автоматический запуск либо заранее спрашивать согласие.

Доставка не давала права на выполнение. Тип, загрузка, декодирование, согласие, запуск и результат были отдельными контролями. Механизм имени и пароля RFC называл небезопасным и оставленным ради совместимости — это историческая оценка, а не современная рекомендация.

RFC 1738 уже позволял каждой схеме задавать способ доступа. RFC 2122 показывает край этого замысла: веб-страница передавала пользователя в среду с состоянием. Принцип Running-Code Primacy помогает не приписывать документу или записи реестра доказательную силу работающей реализации.

Точная история состоит из переходов: названо, распознано, передано, соединено, выбрано, проверено, открыто, доставлено, одобрено, выполнено, наблюдено. Фраза «ссылка сработала» стирает главное различие RFC 2122.

Источники