Résumé

  • RFC 1312 définit un service expérimental de messages courts sur TCP et UDP, dont les champs destinataire et terminal n'identifient pas toujours un écran ou une personne déterminés.
  • La réponse TCP + atteste une remise à un utilisateur ou terminal au sens du service, mais le RFC précise qu'elle peut ne représenter que l'invocation d'un mécanisme local de remise.
  • Le texte ne prescrit pas d'attendre l'affichage, la confirmation par l'utilisateur ou la lecture : une réponse positive ne devient donc pas un reçu d'attention.

Analyse

Une adresse de service n'était pas une présence

Le format de Message Send Protocol 2 assemblait un octet de révision et des champs terminés par nul : destinataire, terminal du destinataire, message, expéditeur, terminal de l'expéditeur, cookie et signature. Sa brièveté ne résolvait pas la question du lieu humain où le message apparaîtrait.

Un destinataire vide pouvait permettre la remise à n'importe quel utilisateur du système. Un terminal vide demandait au système de choisir le terminal « approprié », fonction dépendante du système. Une étoile visait tous les terminaux. Les deux champs vides orientaient la remise vers une console, définie non par l'identité de son lecteur mais comme un endroit probablement visible pour un opérateur ou administrateur. Les champs guident un service local ; ils ne démontrent ni présence, ni sélection humaine, ni attention.

Cette réserve change la portée de la réponse ultérieure. Un serveur peut avoir suivi l'instruction qui lui a été donnée tout en laissant ouvertes les conditions qui rendraient le message socialement atteint : quel écran a été retenu, une personne s'y trouvait-elle, l'affichage a-t-il abouti, le contenu a-t-il été remarqué ? La grammaire du protocole ne transforme pas ces inconnues en certitudes.

Le sens étroit du signe plus

Dans le service TCP, le serveur répondait après réception par un caractère + ou , suivi éventuellement d'une explication. Le plus signifiait une remise réussie à quelque utilisateur ou terminal ; le moins, une absence de remise à tout terminal. C'est une distinction d'exploitation réelle, mais le RFC interdit d'y ajouter un parcours complet jusqu'à un lecteur.

Les auteurs indiquent qu'un accusé positif peut seulement montrer que le serveur Message Send a correctement invoqué un service local de remise. Il pourrait ne pas être possible d'en inférer une sémantique véritable de bout en bout. Le texte énumère les étapes qu'il ne choisit pas : la remise au service local, l'affichage par un système de fenêtres, ou la confirmation par un utilisateur qui ferme une fenêtre surgissante. La spécification ne fixe pas celle à laquelle l'accusé doit correspondre.

Une réponse + est donc une preuve honnête mais limitée. Elle ne prouve pas que le bon écran a montré le texte, que cet écran est resté visible, qu'une personne déterminée était présente, qu'elle a compris, ni qu'elle a consenti à recevoir. Pour chacune de ces affirmations, il faudrait une observation provenant de l'élément qui la rend vraie, et non une extension du sens d'un caractère réseau.

UDP séparait réponse, silence et répétition

Le service UDP pouvait renvoyer un datagramme de réponse. Il devait envoyer un positif lorsqu'un message adressé à un utilisateur précis avait été remis avec succès ; il n'envoyait pas de réponse pour un message destiné à n'importe quel utilisateur ni en cas d'échec. La raison donnée est le risque de réponses excessives aux diffusions. Ici encore, le silence ne se laisse pas nommer simplement « échec », pas plus qu'une réponse ne devient une preuve universelle de fin de chaîne.

Le cookie, combiné au port UDP de l'expéditeur, pouvait aider le serveur à reconnaître un doublon. Un client pouvait émettre plusieurs fois le même message pour améliorer ses chances de réception et le serveur pouvait éliminer les répétitions. Ce mécanisme traite la répétition dans un périmètre défini ; il ne prouve ni la première remise, ni l'affichage, ni l'identité de la personne supposée destinataire.

Une signature textuelle n'était pas une identité vérifiée

RFC 1312 prévoyait un champ SIGNATURE, mais ne définissait ni l'encodage ni l'interprétation du jeton de sécurité qu'il pouvait porter. Une signature vide ne vérifiait pas l'identité de l'expéditeur. Le RFC demandait également de filtrer le texte présenté, car écrire sur un terminal sans permission ou transmettre des séquences dangereuses créait des risques distincts.

Le nom d'expéditeur, le champ signature, l'adresse de transport, la remise locale et la lecture humaine restent ainsi des preuves de natures différentes. Le protocole ne les fusionne pas ; une exploitation prudente ne devrait pas le faire à sa place.

Sources

RFC 1312 est une spécification expérimentale de 1992. Elle ne prouve ni personne réelle, ni affichage, ni lecture, ni consentement, ni identité, ni déploiement ni résultat.