Resumo

  • A RFC 2122 definiu uma URL para um serviço multimídia interativo, não para um objeto de dados; o cliente VEMMI normalmente mantinha uma sessão TCP contínua, por padrão na porta 575.
  • A URL podia escolher o serviço e levar parâmetros nomeados, mas não usuário nem senha. Suporte do navegador, autenticação e VEMMI_Open continuavam sendo etapas posteriores.
  • application/vemmi tratava do transporte separado de objetos, inclusive programas executáveis. Receber, aprovar, executar e obter resultado seguro exigiam registros distintos.

Endereço de um serviço

Publicada como Proposed Standard em março de 1997, a RFC 2122 definiu o esquema VEMMI, a interface homem-máquina aprimorada para videotex e recuperação multimídia. Seu limite central é explícito: a URL não designa um objeto de dados, e sim um serviço multimídia interativo.

vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value> podia nomear host, porta, serviço e pares atributo-valor. Sem porta, valia 575; por segurança, o cliente podia ignorar outra porta indicada. Esses campos descreviam uma tentativa de início. Não provavam DNS, listener, serviço existente nem aceitação dos parâmetros.

O VEMMI normalmente mantinha uma ligação TCP/IP durante a sessão para administrar objetos e reportar ações. A página Web era um ponto de encontro, não o próprio runtime.

O diálogo vinha depois

Após conectar, o servidor podia pedir service:, username: e password:. O cliente usava o serviço da URL, valores configurados ou consultava a pessoa. Até receber VEMMI_Open, o terminal permanecia no modo padrão compatível com videotex ou telnet.

Usuário e senha eram proibidos na URL. Seleção e identidade ocupavam camadas diferentes. Os exemplos 200 OK e 401 Unauthorized mostravam ramos de protocolo, não medições. Link clicado, helper aberto, TCP estabelecido, identidade aceita e sessão iniciada eram recibos separados.

O navegador podia falhar antes do VEMMI

O suporte podia ser embutido ou fornecido por software associado. Sem ele, um navegador rejeitaria o esquema; outro o trataria como URL relativa e pediria ao servidor HTTP da página um caminho inexistente. Portanto, um vemmi:// no HTML não provava sequer a presença de um handler local.

A RFC sugeriu download alternativo do cliente, reconhecimento do pedido relativo incorreto ou uso de Accept: application/vemmi como indício. Não informou cobertura real dessas soluções. Especificação não é adoção.

Objeto e sessão percorriam caminhos diferentes

application/vemmi permitia transportar objetos via HTTP, email ou outros meios sem abrir a sessão contínua. Também podia carregar um texto com a URL a ser ativada. O esquema lançava um caminho de serviço; o tipo de mídia rotulava algo para transporte e decodificação.

A IANA ainda lista vemmi como esquema permanente, application/vemmi e a porta 575. Isso preserva nomes. Não prova manutenção, serviço ativo, tráfego, interoperabilidade ou uso.

Executar exigia outra autorização

Objetos de metacódigo podiam conter comandos; objetos operativos podiam ser programas executados no cliente. A RFC recomendava desativar a execução automática ou pedir aprovação antes.

Entrega não era permissão. Tipo, download, decodificação, consentimento, execução e resultado formavam controles distintos. O mecanismo de usuário e senha era chamado de inseguro e mantido por compatibilidade — afirmação histórica, não orientação moderna.

A RFC 1738 já deixava cada esquema definir seu método de acesso. A RFC 2122 mostra o alcance disso: uma página podia abrir a porta para um ambiente com estado. Running-Code Primacy oferece a disciplina correta: documento e registro não tomam emprestada a autoridade de uma implementação em execução.

O relato preciso é uma sequência: nomear, reconhecer, despachar, conectar, selecionar, autenticar, abrir, entregar, aprovar, executar e observar. Dizer apenas “o link funcionou” apaga justamente a contribuição histórica da RFC 2122.

Fontes