Résumé

  • Le RFC 1861 organisait la transaction de radiomessagerie en états successifs : commande traitée, unité joignable ou message en file, livraison, lecture, réponse et état final.
  • ACKRead demandait une preuve de consultation indépendante de toute réponse ; MSTAtus permettait de suivre les changements au moyen d’un identifiant, d’un code d’accès et d’un numéro de séquence croissant.
  • Ce vocabulaire précis n’effaçait pas les limites : le texte était de statut Informational, la sécurité n’y était pas étudiée, plusieurs choix restaient locaux et l’IETF n’avait pas unanimement préféré un protocole séparé.

Le mot « livré » avait besoin d’une adresse

À quel endroit un message est-il livré ? Dans la mémoire d’une passerelle, dans la file d’un opérateur radio, dans un terminal de poche ou dans l’attention de la personne qui le porte ? La question paraît grammaticale. Elle détermine pourtant qui peut affirmer quoi lorsqu’une alerte n’entraîne aucune action.

Le RFC 1861 a répondu sans chercher une définition universelle. Il a distribué le mot entre plusieurs événements observables. Le serveur pouvait confirmer par 250 qu’une commande avait été traitée. En mode bidirectionnel, PAGEr pouvait annoncer par 850 que l’unité était en ligne et la transaction acceptée, par 950 qu’elle était hors ligne mais que le message serait conservé, ou par 750 que la transaction était refusée. Aucun de ces retours ne disait encore que l’abonné avait lu le texte.

Cette retenue est le vrai sujet du document. La passerelle ne recevait pas, par la simple circulation des octets, un mandat pour parler au nom de la radio, du terminal et de son utilisateur. Elle rapportait l’état de sa propre surface. La précision du système venait moins de la quantité de données que du refus de fusionner les témoins.

Le retour de l’abonné changeait la durée de la transaction

SNPP n’était pas né bidirectionnel. Le RFC 1568, en janvier 1994, décrivait une première version destinée à transmettre une page vers un terminal. Le RFC 1645, publié six mois plus tard, l’avait remplacée par la version 2. En octobre 1995, le RFC 1861 rendait à son tour cette version obsolète et ajoutait un niveau 3 pour les appareils capables d’accuser réception et de répondre.

Dans le modèle initial, la passerelle servait notamment d’adaptateur entre un client Internet et les terminaux parlant TAP/IXO. Le trajet pouvait être compliqué, mais le geste demandé restait linéaire : sélectionner un récepteur, fournir un contenu, lancer l’envoi. La voie de retour ajoutait une durée humaine que le réseau ne pouvait prédire.

Le texte l’expliquait franchement. La livraison et l’accusé technique pouvaient arriver selon un rythme assez prévisible. On ne pouvait pas savoir quand l’abonné sortirait physiquement l’appareil, lirait le message et déciderait de répondre. Il devenait absurde de maintenir un appel téléphonique coûteux pendant cette attente. Le réseau Internet offrait un transport moins dépendant de la durée, à condition que l’état survive à la connexion.

Le niveau 3 était donc orienté vers une seule unité. La commande 2WAY ouvrait la phase bidirectionnelle ; SEND lançait le message et ramenait ensuite le serveur au mode ordinaire. Le client pouvait revenir avec MSTAtus. La continuité appartenait à l’enregistrement de transaction, pas à une session artificiellement prolongée.

Quatre familles au lieu d’un feu vert

Le RFC regroupait les résultats selon leur degré de finalité. Les réponses 86x indiquaient une livraison initiale suivie d’une action encore attendue. Les 87x signalaient un traitement intermédiaire accompli sans clôture. Les 88x étaient finales. Les 96x décrivaient une transaction en file.

Au moment de SEND, 860 voulait dire que le message avait été livré mais que l’accusé de lecture restait attendu ; 861, que la livraison avait eu lieu mais qu’une réponse restait ouverte ; 880, qu’il était livré sans réponse en attente ; 960, qu’il attendait encore sa livraison. Les consultations ultérieures pouvaient produire 870 — livré et lu, réponse toujours attendue — puis 881 pour livré et lu, 888 pour une réponse à choix multiple, ou 889 pour un texte libre. 780 conservait l’échec final : expiration avant livraison.

La série 88x formait une frontière déclarée. Après elle, précisait le document, l’état ne devait plus changer. Une interface qui aurait affiché 860 comme un résultat achevé aurait supprimé la raison même de demander une confirmation de lecture. Une interface qui aurait traduit 960 par « livré » aurait transformé une intention de réessayer en fait radio.

Le numéro ne valait donc pas par sa solennité. Il valait parce qu’il limitait la proposition. Il disait jusqu’où le processus était arrivé et empêchait, si le client respectait la sémantique, qu’un événement intermédiaire usurpe la conclusion.

Voir n’était pas répondre

La commande ACKRead portait la distinction la plus fine. Activée, elle demandait au terminal de signaler le moment où l’abonné consultait réellement le message reçu. Le RFC ajoutait que cette fonction était indépendante de la réponse.

Un appareil pouvait recevoir sans être regardé. Une personne pouvait regarder sans répondre. Elle pouvait aussi répondre sans que ce geste constitue un consentement juridique, une approbation hiérarchique ou la preuve qu’elle disposait du pouvoir d’engager une organisation. Le protocole pouvait établir une chronologie de communication ; il ne pouvait fabriquer la compétence de celui qui communiquait.

RTYPe permettait de ne recevoir aucune réponse, d’offrir oui ou non, d’utiliser des réponses simples définies par le prestataire, de proposer un choix multiple lié au message ou d’accepter du texte libre. Avec MCResponse, l’expéditeur préparait les choix possibles. Une réponse 888 attestait qu’un des codes était revenu par ce chemin. Elle n’attestait ni la compréhension de toutes les conséquences ni l’absence de contrainte.

Cette limite protège les deux côtés. L’expéditeur obtient une information plus précise qu’un silence. Le destinataire n’est pas transformé en autorité générale parce qu’un petit appareil a renvoyé un code.

Refuser la file pouvait être plus honnête

Une file d’attente prolonge la chance de livrer. Elle prolonge aussi l’ambiguïté. Pour une information courante, attendre le retour sous couverture d’un récepteur peut être raisonnable. Pour une alerte qui perd sa valeur après quelques minutes, une file silencieuse peut être plus dangereuse qu’un refus immédiat.

RFC 1861 rendait ce choix explicite avec NOQUEUE. Envoyée avant PAGEr, la commande interdisait la mise en attente pour cette transaction. Une unité hors ligne conduisait alors à un refus de série 750. Le client savait que cette voie ne convenait pas et pouvait chercher un autre moyen de joindre la personne.

EXPTag permettait de modifier le délai d’expiration d’un message en attente. Une fois ce délai dépassé, le message devait être supprimé et son statut indiquer l’absence de livraison. La politique par défaut et la durée de vie des identifiants restaient toutefois dépendantes du fournisseur. La norme proposait une grammaire du délai, non un calendrier universel.

Après lecture finale, KTAG autorisait le client à détruire l’identifiant de suivi au lieu d’attendre le nettoyage automatique. Ce détail reconnaissait qu’un état conservé a un coût et un risque. La preuve doit rester disponible assez longtemps pour terminer ou examiner la transaction, mais sa conservation indéfinie n’est pas une vertu.

L’identifiant ouvrait un dossier, pas une forteresse

Un SEND bidirectionnel réussi ramenait un Message_Tag et un Pass_Code. Le premier fonctionnait comme un numéro de dossier ; le second devait être un code PIN aléatoire autorisant la consultation. MSTAtus associait les deux pour retrouver le dernier état.

Le dossier contenait aussi un numéro de séquence, incrémenté lors des changements, ainsi qu’une date et une heure. Le client pouvait ainsi reconnaître le passage de la livraison à la lecture puis à la réponse, plutôt que prendre chaque consultation pour un nouvel événement.

Il serait pourtant erroné d’en déduire une architecture de sécurité. La section « Security Considerations » se limite à dire que les questions de sécurité ne sont pas discutées. Le RFC ne démontre ni confidentialité, ni authentification forte, ni résistance au devinement du code, ni règles d’autorisation complètes. Le code d’accès limite peut-être une consultation occasionnelle ; la source ne permet pas d’affirmer davantage.

Cette lacune devient plus grave à mesure que le statut s’enrichit. Une base qui connaît l’heure de lecture et la réponse possède une information plus sensible qu’un simple journal d’envoi. L’exactitude de l’observation ne dispense pas de gouverner son accès.

Être joignable sans révéler le lieu

La commande PING pouvait localiser l’unité ou indiquer son état. Le texte reconnaissait immédiatement la sensibilité de cette information. L’abonné pouvait choisir qu’une requête reçoive seulement une réponse générique : unité présente sur le système, aucune localisation disponible. Le RFC appelait ce réglage « ACLU mode ».

La solution était modeste mais conceptuellement nette. Le prestataire pouvait connaître une position sans être obligé de la révéler à l’interrogateur. Disponibilité et localisation devenaient deux attributs séparés.

Le document ne précisait cependant pas comment authentifier le choix de l’abonné, protéger les journaux, régler un conflit ou encadrer une dérogation. La réponse 821 limitait une divulgation ; elle ne constituait pas une politique complète de confidentialité. Là encore, le protocole montrait un levier sans prétendre gouverner toute l’institution qui le manœuvrait.

Le désaccord n’a pas disparu dans le numéro du RFC

L’auteur rapporte que des membres de l’IESG et le groupe « 822 Extensions » avaient préféré une autre stratégie. L’infrastructure de courrier existait déjà à grande échelle. Déployer un protocole supplémentaire coûtait cher. Pour certains relecteurs, une bonne configuration des clients et serveurs de courrier suffisait à obtenir l’exigence « livrer immédiatement ou échouer ». D’autres admettaient des détails propres à la radiomessagerie, mais les imaginaient comme extensions de SMTP.

Le défenseur de SNPP répondait qu’un protocole séparé isolerait les particularités de TAP/IXO et de ses successeurs. Des passerelles pourraient toujours relier le courrier à SNPP sans imposer ces détails aux utilisateurs.

Le dossier bibliographique du RFC Editor conserve le résultat avec le statut Informational. La publication rendait une proposition consultable et implémentable. Elle n’effaçait ni le coût d’adoption, ni l’alternative SMTP, ni la nécessité de vérifier ce qui fut réellement déployé.

Un bon reçu reste plus petit que la réalité

Le serveur connaissait le traitement de la commande. L’opérateur de radiomessagerie connaissait la file et la transmission. L’unité pouvait signaler réception et consultation. La voie retour pouvait porter un choix. Le client voyait la succession des états. Chaque acteur détenait une partie de l’histoire.

La force de RFC 1861 fut de ne pas convertir cette distribution en faiblesse honteuse. Le protocole exposait l’inachèvement. Il permettait à un message d’être correctement « livré » à un appareil tout en restant correctement « non lu » par une personne. Il gardait une réponse ouverte après la lecture et déclarait la clôture seulement lorsque les portions demandées avaient atteint un état final.

Le principe ne doit pas être gonflé en loi universelle. Il fournit plutôt une méthode d’audit. À chaque voyant vert, demander : quel événement a été vu, par quelle surface, et quelle conséquence le système est-il autorisé à en tirer ? La confiance naît de cette limite. Un registre devient moins crédible, et non plus puissant, lorsqu’il prétend transformer une étape observée en résultat humain, institutionnel ou juridique.

Sources