Résumé

  • Le RFC 1176 rendait facultatives certaines commandes IMAP2. Une réponse BAD à FIND MAILBOXES ou FIND BBOARDS ne permettait pas au client de comprendre la cause de l'échec.
  • Le RFC 1203 se présentait comme une contre-proposition : le serveur devait annoncer ses versions et fonctions, puis le client choisir son comportement avant d'ouvrir une boîte aux lettres.

Le bouton « trouver les boîtes aux lettres » avait un problème d'honnêteté. Dans le RFC 1176 d'août 1990, FIND MAILBOXES était facultatif. Si le serveur répondait BAD, le document interdisait au client d'en déduire quoi que ce soit. L'interface pouvait donc proposer une action sans savoir si elle existait de l'autre côté du fil. Il fallait essayer pour apprendre, et l'échec ne livrait même pas une explication nette.

Le RFC 1203, publié en février 1991 sous le nom IMAP3, a attaqué ce point frontalement. Son auteur, John Rice, l'a qualifié de contre-proposition au RFC 1176. Il reprochait aussi à ce dernier d'avoir été rédigé sans consultation interne de la communauté IMAP. Ce récit du processus appartient à Rice; les deux textes permettent en revanche de vérifier la divergence technique sans adopter son jugement sur chaque participant.

Rice voulait que le serveur se présente avant que le client n'agisse. SUPPORTED.VERSIONS demandait les versions et les fonctions disponibles. SELECT.VERSION retenait une version, et SELECT.FEATURES activait ou désactivait des fonctions nommées. L'exemple du RFC fait annoncer les capacités, choisir la version 3.0, puis activer TAGGED.SOLICITED. Une demande portant sur une version ou une fonction absente reçoit NO. Un client peut dès lors ajuster ses menus à ce que le serveur a réellement déclaré.

La riposte n'imposait pas une rupture immédiate. Le comportement initial restait celui d'IMAP2 tel que défini par le RFC 1064. Sans sélection explicite, le serveur ne changeait pas de règles; les anciens clients gardaient leur point d'entrée. Le choix de version devait précéder la sélection de la boîte aux lettres, car un serveur pouvait devoir changer de programme pour appliquer un autre protocole. Mieux valait perdre un état encore vide qu'une session déjà engagée.

Le désaccord touchait aussi l'intérieur du client. L'annexe du RFC 1176 prescrivait un cache local, modèle incomplet de la boîte aux lettres que les réponses du serveur mettaient à jour. Rice refusait qu'un protocole suppose une architecture de cache précise côté poste de travail. Sa distinction entre réponses sollicitées, portant l'étiquette de la commande, et données spontanées, portant *, visait également les recherches simultanées et les réponses tardives sur un stockage lent. Le serveur pouvait travailler à son rythme; le client devait savoir à quelle demande rattacher chaque résultat.

Le registre de l'éditeur des RFC classe aujourd'hui le document parmi les textes Historic. En 1991, son statut pour l'Internet était Experimental. Ces deux mentions ne mesurent ni la diffusion des logiciels ni une victoire commerciale. Elles laissent voir une question plus durable : quand une norme rend un comportement facultatif, qui paie le prix de l'incertitude ? Le RFC 1203 voulait présenter la facture au serveur qui connaissait déjà la réponse.

Sources