Résumé

  • Dans RFC 10022, la taille demandée est un plafond strict, non une quantité garantie. Un intervalle peut représenter moins de messages et ses UID de bord peuvent ne correspondre à aucun message existant.
  • Le résultat OK clôt la fabrication du plan. Pour clôturer l’opération, il faut encore rattacher ce plan à la boîte et à son UIDVALIDITY, suivre EXISTS, EXPUNGE ou VANISHED, puis conserver les résultats réels de FETCH, STORE, COPY, MOVE ou de toute autre commande exécutée.

Le planificateur n’est pas l’archiviste

Une boîte sélectionnée contient 6 823 messages. Le client demande UIDBATCHES 2000. Quatre intervalles reviennent, du plus récent au plus ancien, puis le serveur répond OK. Pour un ordonnanceur, la tentation est immédiate : créer quatre tâches, afficher quatre cases et appeler l’ensemble « inventaire de la boîte ».

Ce dernier mot est faux.

Le serveur a calculé quatre zones de travail dans l’espace des UID. Il n’a pas produit la liste des objets présents. Il n’a pas lu leur contenu. Il n’a déplacé, copié ou modifié aucun message. Il n’a pas empêché une suppression pendant la seconde suivante. Il n’a pas non plus réservé les nouveaux UID qui naîtront au-dessus de la borne la plus élevée.

UIDBATCHES est précieux justement parce qu’il reste plus modeste qu’un instantané. Un client peut préparer des commandes de taille raisonnable sans connaître les numéros de séquence, notamment sous UIDONLY. Le serveur garde la liberté d’utiliser un chemin de calcul efficace. Les deux côtés disposent d’un langage commun, sans faire croire qu’un verrou global a été posé sur la boîte.

Le risque de gouvernance apparaît lorsque le tableau de bord transforme « plan calculé » en « population maîtrisée », puis « population maîtrisée » en « opération terminée ». Trois affirmations différentes deviennent une seule couleur verte.

Deux mille fixe le maximum, pas la promesse

Le nombre placé après la commande possède une autorité asymétrique. Un intervalle ne doit jamais contenir plus de messages que le nombre demandé. En revanche, il peut en contenir moins.

RFC 10022 invite le serveur à rester proche de la taille souhaitée et à viser au moins 90 % lorsque c’est possible. Cette cible n’est pas une obligation d’exactitude. Deux circonstances autorisent explicitement une population inférieure : un découpage sensiblement plus simple ou plus efficace pour l’implémentation, et un changement de la boîte pendant le calcul, en particulier une expulsion de messages.

La bonne lecture de 2000 est donc « au plus 2 000 messages existants par zone », jamais « reçu certifié pour 2 000 objets ». Le planificateur peut dimensionner la mémoire et la charge à partir du plafond. Le contrôleur d’exécution doit compter ce que la commande suivante a réellement rencontré.

La limite basse de 500 messages complète ce contrat. Une demande plus petite reçoit TOOFEW. La mesure protège les ressources du serveur, mais elle protège aussi l’intention de UIDONLY. Si un client pouvait demander des lots d’un seul message, il reconstruirait presque les positions que ce mode retire. Le protocole fournit une granularité de travail, non un canal détourné vers l’ordre interne de la boîte.

Ainsi, l’autorité se partage. Le client choisit une enveloppe utile. Le serveur calcule des bornes valides. Le standard fixe les limites communes. Aucun des trois n’atteste une cardinalité exacte.

Les bornes peuvent tomber dans le vide

Dans une génération de boîte, les UID montent, mais ils ne forment pas nécessairement une suite pleine. Les suppressions laissent des lacunes. Le serveur peut aussi choisir une borne pratique qui se trouve entre deux messages présents. RFC 10022 permet donc qu’un UID situé au début ou à la fin d’un intervalle ne désigne aucun message stocké.

Ce choix ne rend pas l’intervalle mensonger. Une clôture géographique peut traverser un terrain vide sans prétendre qu’un bâtiment occupe chaque coin. De la même manière, 163886:99703 signifie : appliquer la commande ultérieure aux messages existants dont l’UID appartient à cette zone. Il ne signifie pas que les messages 163886 et 99703 existent.

La dernière zone peut se terminer à l’UID 1 alors que le plus ancien message réel porte l’UID 302. La valeur 1 indique sans ambiguïté que le client a atteint le bas de l’espace utile. Elle ne crée pas un message numéro 1.

Cette nuance doit vivre dans le modèle de données. Les deux bornes sont des paramètres de sélection, pas deux objets vérifiés. La largeur numérique n’est pas un compteur. Une interface qui affiche la borne comme un message trouvé fabrique une preuve que le serveur n’a jamais émise.

L’identité durable reste celle d’IMAP : nom de boîte, UIDVALIDITY et UID. Le plan ajoute une époque de traitement. Il ne remplace ni la génération de boîte ni la vérification du contenu associé à l’UID.

Une bande ancienne ne gagne pas de nouveaux messages

La monotonie des UID fournit une propriété utile. Une fois les intervalles retournés, un nouveau message reçoit une valeur supérieure ; il ne s’insère pas au milieu d’une bande ancienne. Le plan conserve donc son contour.

Sa population peut pourtant diminuer. Chaque EXPUNGE ou VANISHED enlève un membre potentiel. Un lot qui représentait environ 2 000 messages peut n’en livrer que 1 987 lors du FETCH. L’intervalle reste valable, mais la phrase « 2 000 messages traités » ne l’est plus.

Les arrivées créent une zone au-dessus de l’ancien maximum. Elles ne modifient pas les vieilles bornes ; elles modifient la définition de « toute la boîte ». Une opération bornée à un instant peut les remettre à l’époque suivante. Une synchronisation continue peut ouvrir aussitôt un nouveau lot. Cette décision appartient au service, pas à la syntaxe de la commande.

Le recalcul est lui aussi borné. Le client ne doit pas relancer UIDBATCHES pour rafraîchir l’esthétique de son écran. La relance convient lorsqu’une autre boîte est sélectionnée, lorsque plus de la moitié d’un lot a été expulsée ou lorsque plus de la moitié d’un lot de nouveaux messages est arrivée. Le serveur devrait surveiller cette pression et peut répondre LIMIT.

Ces seuils arbitrent le coût de calcul. Ils ne définissent pas une politique de conservation, de migration ou de gel légal. Un opérateur peut exiger une preuve plus stricte pour une suppression irréversible sans demander au serveur de recalculer sans fin.

Un OK vide n’est pas une contradiction

Même sans intervalle, le serveur doit émettre la réponse non étiquetée UIDBATCHES, avec le corrélateur du tag de commande, puis terminer la commande. Une boîte vide produit naturellement ce résultat. Une fenêtre de lots inexistante le produit aussi.

Prenons une boîte qui ne possède que quatre lots. Si le client demande les lots 6 à 8, la réponse correcte ne contient aucune plage et se termine néanmoins par OK. Le serveur a exécuté une demande valide ; il n’a rien trouvé dans la fenêtre demandée.

Pour interpréter ce vide, il faut conserver le contexte : compte, boîte sélectionnée, UIDVALIDITY, tag, taille de lot, fenêtre d’indices et état observé. Retirer ces éléments transforme une réponse précise en ambiguïté opérationnelle.

Les autres statuts ne doivent pas non plus être aplatis. TOOFEW signale une granularité trop fine. TOOMANY borne une réponse ou une fenêtre trop vaste. LIMIT protège contre les recalculs abusifs. CLIENTBUG peut identifier une fenêtre d’indices écrite dans le mauvais sens. Chaque état conduit à une correction différente.

Une plateforme qui remplace ces distinctions par « erreur de pagination » accroît son propre enfermement. L’équipe dépend alors d’un comportement privé pour deviner quel coût, quelle syntaxe ou quel état a réellement bloqué le travail.

Cent mille messages dessinent une frontière de coût

Une fenêtre explicite ne doit pas couvrir plus de 100 000 messages. Le serveur doit au moins savoir retourner des intervalles couvrant cette population. Une demande sans fenêtre portant sur une boîte immense peut toutefois recevoir TOOMANY.

Ce point révèle une limite saine. Le client n’a pas un droit illimité au calcul global du serveur. Le serveur n’a pas le droit de rendre l’extension inutilisable sous le seuil commun. Le standard construit un noyau d’interopérabilité puis laisse la capacité supérieure à l’implémentation et au contrat local.

Pour parcourir une grande boîte par fenêtres successives, le document propose un chevauchement : 1:100, puis 100:200. La répétition de la frontière permet de détecter une incohérence entre deux calculs effectués pendant que la boîte évolue.

Le chevauchement est un témoin, pas un verrou. Deux réponses concordantes renforcent la confiance dans la continuité. Elles ne prouvent pas l’absence de suppression entre les lectures et ne choisissent pas automatiquement quelle version conserver si elles divergent.

Le professionnel doit donc enregistrer la comparaison, son heure et la décision qui en résulte. Sinon, le coût supplémentaire du chevauchement est payé sans produire l’audit qu’il devait acheter.

Les extensions voisines conservent leur métier

UIDONLY interdit les numéros de séquence une fois activé et remplace notamment les annonces d’expulsion par VANISHED. UIDBATCHES fournit des plages grossières d’UID ; il ne réintroduit pas l’autorité positionnelle supprimée. Le plan reste compatible avec une boîte qui bouge.

PARTIAL répond à une autre question. Il pagine les résultats réels d’un SEARCH ou limite les réponses d’un UID FETCH. UIDBATCHES prépare des bornes réutilisables avant ces opérations. Une page de résultats n’est pas un plan, et un plan n’est pas une page de résultats.

SEARCHRES enregistre un résultat de recherche dans $. RFC 10022 interdit à UIDBATCHES de remplir cette variable, car la commande n’est ni SEARCH ni UID SEARCH. Cette interdiction empêche la promotion silencieuse d’intervalles approximatifs en ensemble de messages.

QRESYNC et CONDSTORE apportent des traces de changement, des séquences de modification et des informations VANISHED. Ils aident à constater la dérive. Ils ne rendent pas actuel un ancien plan par rétroactivité.

Enfin, MESSAGELIMIT annonce la quantité que des commandes ultérieures peuvent réellement traiter. Le client devrait demander des lots qui ne dépassent pas cette limite. Un intervalle valide de 2 000 messages n’autorise pas un seul FETCH de 2 000 si le serveur limite ce verbe à 1 000.

L’ensemble utilisable est l’intersection des contrats. Accumuler les noms de capacités dans une réponse CAPABILITY ne suffit pas ; il faut calculer ce que leur combinaison permet pour le verbe, la boîte et l’époque concernés.

La clôture se fait par populations

Une barre « quatre lots sur quatre » mesure l’activité du planificateur. Pour mesurer l’effet, il faut plusieurs populations :

Ensemble Question
P Quels messages appartiennent à la politique du travail et à cette génération de boîte ?
B Quels messages existants étaient atteignables par les intervalles au moment du plan ?
A Quels messages ont réellement été adressés par les commandes suivantes ?
C Quels messages ont reçu un résultat terminal accepté ?
X Quels messages attendus ont été vus comme expulsés ou disparus ?
N Quels nouveaux messages sont arrivés au-dessus de l’ancien maximum ?
U Quels résultats restent inconnus ou doivent être repris ?

Une exportation bornée peut exiger P = C ∪ X, avec U vide et une justification pour chaque membre de X; N entre alors dans l’époque suivante. Une synchronisation continue peut ouvrir une nouvelle bande pour N sans fermer l’ancienne. Le protocole ne choisit pas entre ces politiques.

L’égalité porte sur les membres, pas seulement sur les nombres. Une suppression et une arrivée peuvent maintenir le même total tout en changeant l’identité de la population. Il faut joindre le nom de boîte, UIDVALIDITY, UID, époque et résultat de commande.

Le commandement partagé reste mince : des identifiants, des limites et une syntaxe vérifiable. Les choix futurs restent locaux. Cette architecture correspond à l’idée de Heng Lu selon laquelle la coordination doit préserver les invariants nécessaires sans transformer la publication d’une règle en gouvernement de chaque effet.

Ce que le dossier public ne démontre pas

RFC 10022 ne prouve pas qu’un fournisseur nommé déploie UIDBATCHES, qu’un client respecte la discipline de recalcul ou qu’un serveur donné atteint la cible de 90 %. Les situations décrites ici sont des tests de fonctionnement dérivés des états permis par le standard, non des incidents attribués.

Le registre IANA établit le sens commun de UIDBATCHES, TOOFEW et TOOMANY. Il n’inspecte aucun binaire et n’exécute aucune commande. Une annonce CAPABILITY appartient à la couche déclarative ; la réponse appartient à la couche d’état ; les résultats de FETCH, COPY ou MOVE appartiennent à la couche d’effet.

La primauté du code en fonctionnement n’autorise pas non plus le serveur à inventer le contrat. Elle exige que la réalité observée puisse contredire une synthèse trop ambitieuse. Un intervalle correctement formé reste un fait utile. Il devient trompeur seulement lorsqu’on lui prête l’effet d’une commande qu’il n’a pas exécutée.

Sources