Résumé

  • La RFC 2122 définissait l’adresse d’un service multimédia interactif, non celle d’un objet ; le client VEMMI établissait normalement une session TCP continue, par défaut sur le port 575.
  • L’URL pouvait choisir le service et transporter des paramètres nommés, mais jamais le nom d’utilisateur ni le mot de passe. Le support du schéma, l’authentification et VEMMI_Open restaient des étapes ultérieures.
  • application/vemmi servait au transport d’objets. Certains objets opératifs étaient des programmes exécutables : réception, approbation, exécution et résultat sûr n’étaient donc pas synonymes.

Une adresse de service

Publiée en mars 1997 comme Proposed Standard, la RFC 2122 inscrivait VEMMI — Enhanced Man-Machine Interface for Videotex and Multimedia/Hypermedia Information Retrieval Services — dans le modèle d’aiguillage du Web. Elle précise que son URL ne désigne pas un objet de données. Elle désigne un service interactif auquel un logiciel client doit se connecter.

La forme vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value> pouvait indiquer un hôte, un port, un service et des paramètres étiquetés. Sans port explicite, 575 s’appliquait ; le client pouvait néanmoins ignorer un autre port demandé par l’URL pour des raisons de sécurité. Cette syntaxe décrivait une intention. Elle ne prouvait ni la résolution de l’hôte, ni l’écoute du port, ni l’existence du service.

VEMMI fonctionnait en principe sur une liaison TCP/IP maintenue pendant toute l’interaction. Les actions de l’utilisateur pouvaient remonter au serveur au fil de la session. Le Web n’absorbait donc pas le service : il lui fournissait un rendez-vous.

Le dialogue venait après le clic

Une fois la connexion établie, le serveur pouvait demander service:, username: et password:. Le client reprenait éventuellement le service de l’URL, consultait sa configuration ou interrogeait l’utilisateur. Le terminal demeurait en mode « standard », compatible vidéotex ou telnet, jusqu’à la réception de VEMMI_Open.

Le texte interdit d’inscrire l’identifiant et le mot de passe dans l’URL. Les exemples 200 OK et 401 Unauthorized montrent des branches du dialogue, pas des résultats mesurés. Un lien sélectionné, un programme auxiliaire lancé, une socket ouverte et une commande d’ouverture reçue constituent quatre pièces distinctes. Aucune ne démontre à elle seule une identité authentifiée, une autorisation ou un service rendu.

L’échec pouvait précéder le réseau VEMMI

La prise en charge pouvait être native au navigateur ou fournie par un logiciel associé. Sans elle, certains navigateurs refusaient le schéma inconnu ; d’autres le traitaient comme une URL relative et interrogeaient par erreur le serveur HTTP de la page, qui répondait généralement « not found ».

La présence du lien dans un document HTML ne prouvait donc même pas l’existence d’un répartiteur local. La RFC proposait des palliatifs — téléchargement séparé du client, reconnaissance de la requête erronée, consultation de Accept: application/vemmi — sans fournir de taux de mise en œuvre. Il faut conserver cette incertitude.

Le type média ne lançait pas la même chose

application/vemmi permettait de transporter des objets VEMMI par HTTP, courrier électronique ou d’autres voies. Un client pouvait demander un objet par HTTP sans ouvrir la session VEMMI continue. Le type média pouvait aussi envelopper un fichier texte contenant une URL VEMMI.

Le schéma nommait un parcours vers un service ; le type média décrivait un objet à transporter et décoder. Leur proximité ne les rendait pas interchangeables. Aujourd’hui encore, l’IANA répertorie le schéma vemmi comme permanent, le type application/vemmi et le port 575. Ces registres attestent des attributions de noms, pas une exploitation actuelle, une interopérabilité ou une adoption.

L’exécution exigeait une autorisation propre

La RFC distinguait les objets de métacode, porteurs de commandes, des objets opératifs, qui pouvaient être des programmes exécutables sur le poste client. Elle recommandait fortement de désactiver leur lancement automatique ou, au minimum, d’exiger l’accord de l’utilisateur.

Le transport ne donnait donc aucun droit d’exécution. Identifier le type, télécharger, décoder, approuver et exécuter formaient une autre chaîne. Même l’accord ne garantissait ni compatibilité de plate-forme ni innocuité. Le mécanisme d’identification par mot de passe était lui-même qualifié d’insûr et conservé pour compatibilité : constat historique de 1997, non conseil moderne.

La RFC 1738 avait prévu que chaque schéma définisse sa méthode d’accès. La RFC 2122 montre jusqu’où cette souplesse pouvait aller : une page Web lançait un environnement avec état. La discipline de Running-Code Primacy aide à lire ce dossier sans extrapoler : une spécification ou une inscription au registre n’emprunte pas l’autorité d’un système réellement exécuté.

L’histoire exacte doit donc conserver une suite de transitions : nommer, reconnaître, aiguiller, connecter, sélectionner, authentifier, ouvrir, livrer, approuver, exécuter, observer. Écrire simplement « le lien a fonctionné » efface précisément ce que la RFC 2122 rend visible.

Sources