Résumé

  • Un serveur IMAP peut fournir les informations demandées par une recherche tout en refusant son option de mise à jour continue. La réussite finale de la commande ne supprime pas ce refus.
  • Réduire le nombre de lignes affichées ne réduit pas automatiquement le périmètre des changements suivis. Une fenêtre PARTIAL et un contexte UPDATE ne représentent pas la même charge.
  • Le produit doit distinguer résultat disponible, suivi accepté et suivi terminé. Sinon, une limite de ressources devient une promesse de fraîcheur que personne n’a réellement prise en charge.

Le budget d’une recherche semble facile à comprendre : une requête arrive, le serveur travaille, une réponse repart. Cette représentation devient trompeuse lorsque le résultat doit rester vivant après la fin de la commande. Le travail initial est terminé, mais une obligation nouvelle commence.

Dans une messagerie, un filtre peut sélectionner les messages non traités, les présenter dans un ordre choisi et maintenir un compteur. À chaque arrivée, changement de drapeau ou suppression, il faut déterminer si le résultat évolue. Le coût se prolonge bien au-delà de l’ouverture de la vue, parfois sans nouvelle action visible de l’utilisateur.

C’est précisément ce service continu que le serveur peut ne pas avoir accepté. L’utilisateur peut pourtant voir une première liste exacte et une application parfaitement réactive. Il manque alors une information essentielle : cette liste sera-t-elle entretenue, ou faudra-t-il la demander de nouveau ?

Il s’agit ici d’une situation illustrative, non d’un incident attribué à un fournisseur. Elle permet d’examiner une décision concrète prévue par RFC 5267, Contexts for IMAP4, publié en juillet 2008. Le serveur peut refuser l’option UPDATE, qui demande la notification des changements ultérieurs, tout en honorant les autres options de retour. La commande de recherche peut ensuite se terminer par une réponse de succès.

Ce résultat n’est contradictoire que si l’on suppose que la recherche et son entretien constituent une seule prestation indivisible. Le protocole les sépare. Une interface qui les réunit doit savoir les distinguer lorsque l’une des deux n’est pas disponible.

Une limite explicite vaut mieux qu’une souscription imaginaire

Le refus prend la forme d’une réponse NO non étiquetée portant le code NOUPDATE. L’argument de ce code contient l’étiquette de la commande concernée. Un plafond interne du nombre de contextes de mise à jour est l’une des raisons envisagées par la spécification.

Les autres options demandées doivent néanmoins être honorées. Le client peut donc recevoir les informations attendues pour la recherche initiale sans avoir obtenu le suivi des changements. Lire seulement la dernière réponse positive ferait disparaître la décision intermédiaire qui détermine l’avenir de la vue.

Cette latitude n’autorise pas le serveur à refuser indistinctement toute mise à jour. RFC 5267 impose au moins un contexte actualisé par client et recommande d’en fournir davantage. Cette exigence minimale ne devient pas pour autant un droit à un nombre illimité de vues, à un volume déterminé de mémoire ou à une fréquence contractuelle de livraison.

Le coût varie aussi avec la nature de la recherche. Les contextes triés sont plus coûteux à mettre en œuvre que les contextes non triés. Refuser une mise à jour pour SORT ne signifie donc pas qu’un contexte SEARCH sera lui aussi refusé. Le document évoque le recours à une recherche non triée ou l’annulation d’un contexte existant parmi les réponses possibles du client.

Une telle adaptation reste une décision de produit. Si l’ordre demandé sert à traiter les messages par priorité, le supprimer sans explication change la tâche. Le serveur peut offrir une capacité plus modeste ; l’application ne doit pas la présenter comme l’exécution inchangée de la demande initiale.

La petite fenêtre peut cacher une grande obligation

Trois options interviennent dans cette famille de fonctions, sans se substituer les unes aux autres. CONTEXT signale que les mêmes critères seront probablement réutilisés. Le serveur peut utiliser cette indication pour conserver un index ou des résultats, mais il peut aussi l’ignorer. Ce n’est pas un ordre de créer un instantané.

UPDATE demande les modifications du résultat complet. Il n’exige pas qu’un contexte ait été préalablement créé au moyen de l’indication CONTEXT. Les ajouts et retraits sont transmis au client pour lui permettre de maintenir le résultat.

PARTIAL choisit une tranche à retourner. Cette tranche ne définit pas le périmètre des mises à jour. Un client qui n’affiche qu’une petite partie de la liste peut recevoir des changements concernant des messages situés ailleurs dans l’ensemble des correspondances.

Ce détail a une portée économique immédiate. La densité de l’écran ne mesure pas le travail permanent du serveur. Réduire les lignes visibles peut diminuer le transfert initial sans supprimer l’obligation de suivre les critères sur l’ensemble pertinent.

RFC 9394, publié en 2023, étend PARTIAL et maintient explicitement cette distinction. Il permet notamment de compter les positions depuis la fin des résultats et ajoute un modificateur à UID FETCH. La capacité PARTIAL ne doit pas être confondue avec CONTEXT=SEARCH : les fonctions à combiner doivent être effectivement annoncées.

L’extension montre également pourquoi le volume retourné ne décrit pas toujours l’état conservé. Dans les combinaisons précisées par le texte, SAVE avec PARTIAL peut enregistrer seulement la partie retournée ; l’ajout de COUNT fait porter l’ensemble enregistré sur toutes les correspondances. La petite réponse et le grand ensemble peuvent ainsi coexister. Cela ne prouve aucune quantité de mémoire consommée par une implémentation particulière, mais interdit d’en déduire la portée à partir du seul nombre de lignes reçues.

De même, UPDATE accompagné d’un COUNT initial ne promet pas une nouvelle valeur COUNT à chaque changement. Le client peut entretenir son compteur à partir des entrées et sorties du résultat. C’est une responsabilité locale, pas une répétition automatique de toutes les informations initialement demandées.

L’étiquette continue à travailler après la commande

L’étiquette portée par NOUPDATE permet de rattacher le refus à la bonne demande. Elle est particulièrement importante lorsque plusieurs recherches ou vues sont actives sur une même connexion.

Le refus intervient pendant le traitement de cette commande. Il ne faut pas le transformer en annonce de suppression de tous les contextes déjà acceptés. Il ne faut pas davantage l’effacer au motif que la recherche s’est terminée correctement. Le client doit conserver une représentation de l’admission du suivi, distincte de celle de la disponibilité du résultat.

Une recherche actualisée conserve aussi une relation avec son étiquette après la réponse initiale. Les notifications ultérieures s’y rapportent. RFC 5267 exige le rejet d’une nouvelle recherche UPDATE si elle réutilise une étiquette encore occupée par une recherche actualisée précédente.

Cette identité est limitée à sa fonction de corrélation. Elle ne devient ni un identifiant métier durable, ni une preuve d’autorisation, ni le nom permanent d’une boîte aux lettres. Sa persistance suffit toutefois à contredire une hypothèse commode : une commande terminée n’a pas nécessairement cessé de structurer les réponses futures.

Pour le produit, la question est simple. Quel état de l’application indique qu’une vue a obtenu son premier résultat mais pas son entretien ? Si cet état n’existe pas, le refus risque d’être enregistré dans un journal sans jamais modifier ce que l’utilisateur croit avoir acheté.

Maintenir une liste exige de respecter son ordre

Une fois le suivi admis, les notifications ne sont pas des éléments que l’on peut réordonner librement. Le client doit traiter ADDTO et REMOVEFROM dans leur ordre d’arrivée, y compris lorsqu’une réponse contient plusieurs éléments. Le serveur doit produire les changements de façon à conserver l’ordre demandé pour les résultats.

Les numéros de séquence des messages imposent des dépendances supplémentaires. Lorsque de nouveaux messages arrivent ou sont ajoutés à la boîte, l’ajout fondé sur ces numéros doit suivre la notification EXISTS. Lorsqu’une suppression définitive provoque un retrait du résultat, ce retrait doit précéder EXPUNGE, afin que les numéros gardent encore le sens nécessaire à son traitement.

Le but est de maintenir correctement un résultat courant. Ce mécanisme n’est pas un journal métier complet, durable et globalement ordonné. Une vue des messages restant à traiter ne raconte pas automatiquement tous les changements de responsabilité ni les décisions prises pendant une interruption.

Les notifications devraient être transmises rapidement lorsque les résultats changent. RFC 5267 ne fixe pas pour autant une borne de latence universelle. Un engagement commercial plus précis doit être observé et financé comme tel, avec une façon de signaler les périodes où il ne peut être respecté.

Le suivi a également une fin. Il cesse lorsque la boîte n’est plus sélectionnée, ou lorsque le client utilise CANCELUPDATE pour les étiquettes concernées. Le serveur peut libérer les ressources associées ; le client reste libre de refaire une recherche. Recréer le contexte peut rétablir une vue actuelle sans reconstituer les transitions perdues entre-temps.

Le cache ne change pas le sens du résultat

L’implémentation peut conserver des résultats, même si le client n’a pas fourni l’indication CONTEXT. Mais son comportement observable doit rester identique, qu’un cache interne soit utilisé ou non. Ce cache doit donc suivre les changements de la boîte ou être abandonné lorsqu’il ne convient plus.

Cette obligation protège la sémantique tout en laissant une marge d’optimisation. La conservation en mémoire n’instaure pas un instantané au bénéfice du client. L’éviction n’autorise pas non plus à changer la signification d’une recherche suivante.

L’annexe de RFC 5267 décrit plusieurs compromis. Pour certaines recherches non triées, comparer les anciens et nouveaux drapeaux avec les critères peut suffire à décider d’un ajout ou d’un retrait. Une recherche partielle peut être recalculée jusqu’à la fenêtre demandée. Les contextes triés nécessitent plus probablement des résultats conservés. Après suppression d’un message, certaines informations peuvent ne plus être disponibles sans état antérieur.

Ce sont des stratégies d’implémentation, non une mesure de performance. Leur intérêt est de montrer que supprimer un cache ne supprime pas forcément le travail continu. Le coût peut simplement passer de la mémoire au recalcul, ou devenir plus difficile à maîtriser lors de certains changements.

Les textes suivants demandent une lecture prudente

RFC 5465, The IMAP NOTIFY Extension, paru en 2009, ajoute un contrôle plus large des notifications non sollicitées. Avec les capacités de contexte correspondantes, il permet aussi de demander des attributs FETCH lorsqu’un nouveau message entre dans le résultat actualisé.

La gestion de ses limites distingue le refus initial d’une demande NOTIFY trop coûteuse et la désactivation ultérieure de notifications. Dans ce dernier cas, une réponse OK non étiquetée portant NOTIFICATIONOVERFLOW est envoyée et le serveur se comporte comme après NOTIFY NONE. Cela ne doit pas être assimilé au refus NOUPDATE d’une nouvelle recherche, ni servir à inventer des conséquences d’annulation entre toutes les extensions.

Le registre des errata de RFC 5465 contient une correction particulièrement pertinente pour la continuité. L’erratum technique vérifié 2318 inverse un exemple qui demandait l’état d’une boîte avant d’organiser les notifications. Il faut d’abord organiser celles-ci, puis demander l’état, pour éviter un intervalle où des changements pourraient ne jamais être signalés.

Le succès des deux commandes ne suffit donc pas à prouver que leur enchaînement assurait une observation continue. Cette correction porte sur un exemple du standard ; elle ne constitue pas la preuve d’un incident actuel chez un fournisseur.

Le même registre conserve l’erratum technique 4833 au statut Reported. Il relève des exigences contradictoires sur l’ordre relatif de FETCH et ESEARCH dans deux sections. Aucune séquence corrigée et définitivement établie ne doit être déduite de cette seule entrée. La mention d’un comportement déployé par son auteur est un témoignage historique, pas un recensement contemporain. Les corrections éditoriales vérifiées concernent une faute de frappe, des parenthèses et un renvoi de section, sans trancher ce conflit technique.

Les recherches d’errata pour RFC 5267 et RFC 9394 n’ont retourné aucun enregistrement correspondant au moment de cette étude. Cela ne garantit pas l’absence de défauts dans les produits. Aucun compte de messagerie ni comportement d’implémentation n’a été testé ici.

Une promesse commune, plusieurs centres de coût

Le suivi continu évite au client de redécouvrir sans cesse les mêmes informations. Cette économie est réelle. Elle suppose néanmoins que quelqu’un conserve et traite ce qui rend le suivi possible. Des utilisateurs autorisés peuvent eux-mêmes créer assez de contextes pour peser sur le service ; RFC 5267 évoque donc limites, stratégies d’implémentation et journalisation.

La question n’est pas de condamner le refus. Elle est de savoir qui adapte la promesse lorsque le refus intervient. Une infrastructure peut protéger ses ressources tout en rendant un résultat initial exact. Le produit ne peut en déduire une couverture qu’elle n’a pas acceptée.

Dans son texte sur le problème d’agence, Lu Heng propose de rapprocher pouvoir de décision et conséquences économiques. Appliquée ici, cette grille relie l’équipe qui promet la fraîcheur, celle qui accepte le travail permanent et les utilisateurs qui supportent les décisions prises sur une vue vieillissante.

Son texte sur la raison d’être de BTW invite également à décrire les structures plutôt qu’à distribuer les rôles de coupable et de victime. Les RFC ne prouvent ni dissimulation par un développeur, ni sous-dimensionnement d’un service. Ils rendent simplement visible un contrat que l’interface peut masquer : obtenir une réponse et payer pour qu’elle reste utile sont deux décisions.