Summary

  • Le code INPROGRESS défini par RFC 9585 est envoyé dans un OK non étiqueté. Il peut donner un décompte, laisser le total inconnu ou servir uniquement à maintenir la connexion.
  • Seule la réponse finale portant l’étiquette de la commande en constate l’issue. Le contenu d’un résultat et ses effets dans d’autres systèmes demandent encore des preuves distinctes.

Une jauge presque pleine possède une force politique surprenante. Dans une salle d’exploitation, elle réduit l’inquiétude. Dans un flux automatisé, elle invite à préparer l’étape suivante. Dans un rapport de service, elle ressemble déjà à une promesse tenue.

Avec INPROGRESS, cette ressemblance doit être combattue. Le serveur peut annoncer 999 unités traitées pour un objectif de 1 000, puis découvrir une nouvelle phase, revoir l’objectif ou faire reculer la valeur. La commande peut encore échouer. Et les unités comptées ne sont pas nécessairement les objets qui constitueront le résultat.

La norme publiée en mai 2024 répond pourtant à un vrai défaut d’observabilité. Certaines recherches, copies ou opérations de maintenance IMAP prennent assez de temps pour que le client soupçonne une rupture. Une phrase libre telle que « toujours en cours » pouvait rassurer un humain, mais pas alimenter un comportement interopérable. RFC 9585 en fait un signal structuré.

Tout commence par CAPABILITY. Un serveur qui prend en charge l’extension doit y publier INPROGRESS. Cette annonce atteste une capacité de protocole, pas l’émission garantie d’un message pour chaque commande. Une opération brève peut se terminer avant la première échéance de notification et ne produire aucun signal intermédiaire.

Lorsque le serveur choisit de notifier, la recommandation est d’émettre un message toutes les dix à quinze secondes. La finalité peut être modeste : empêcher le client de fermer la connexion pour inactivité. La forme la plus nue ne contient aucun détail. Étiquette de commande, progression et objectif sont alors tous compris comme NIL.

La forme détaillée ajoute un triplet. CMD-TAG tente de rattacher le signal à la commande d’origine. PROGRESS compte les éléments déjà traités. GOAL décrit, s’il est connu, le total que la progression devrait atteindre une fois la commande achevée. Quand un décompte d’objets n’a pas de sens, le serveur peut employer une échelle en pourcentage, avec 100 pour objectif et une progression limitée à 99.

La syntaxe reconnaît l’incertitude au lieu de la masquer. Si le progrès est inconnu, progrès et objectif valent NIL. Si seul le total manque, l’objectif reste NIL. Si l’étiquette est indisponible ou contient ], elle devient elle aussi NIL. Ce dernier cas demeure exploitable avec une seule commande en vol. Il devient ambigu lorsque plusieurs travaux partagent la même session.

Un client robuste ne traite pas l’objectif comme un contrat. La norme préfère une progression croissante et un objectif stable, mais elle impose de supporter l’inverse. Une baisse de la progression ou un nouvel objectif s’interprète de préférence comme la découverte d’un travail supplémentaire après l’achèvement d’un lot antérieur. C’est une règle de continuité, non une certification de la quantité totale ni du délai restant.

La grammaire d’IMAP fournit la séparation essentielle. Une réponse commençant par * est non étiquetée : elle transmet des données ou un état qui ne termine pas la commande. La réponse d’achèvement reprend l’étiquette choisie par le client et vaut OK, NO ou BAD. C’est pourquoi RFC 9585 interdit INPROGRESS dans une réponse étiquetée. Le progrès se situe avant la conclusion, jamais à sa place.

Une succession de signaux peut donc aboutir à un succès, à un échec ou à une erreur de protocole. Elle confirme qu’un serveur émet des observations. Elle ne réserve pas un OK futur. Toute action dépendant du succès doit attendre la réponse finale correspondante.

Même ce OK final ne fournit pas forcément le contenu recherché. L’exemple SEARCH est précis : des notifications décrivent le nombre d’éléments traités ; une réponse SEARCH non étiquetée livre ensuite les identifiants des messages correspondants ; le OK étiqueté clôt enfin la commande. Trois questions, trois pièces : le travail avance-t-il, qu’a-t-il trouvé, s’est-il achevé avec succès ?

La norme interdit explicitement d’utiliser GOAL à la place de la sortie SEARCH pour connaître le nombre de messages d’un dossier. L’objectif n’est pas la cardinalité des résultats. Avec COPY, le même raisonnement interdit d’assimiler les unités parcourues aux copies durablement enregistrées, indexées, répliquées ou reconnues par une chaîne d’archivage.

Le silence n’autorise pas davantage de conclusions. Avant la première notification, le client doit supposer une progression nulle et un objectif inconnu. Cela décrit son état de connaissance, pas l’état interne du serveur. Une commande rapide peut réussir sans aucun message intermédiaire. Inversement, un battement régulier peut ne témoigner que de la volonté de garder la connexion ouverte.

La section de sécurité oblige aussi à traiter le serveur comme une source potentiellement hostile. Des valeurs incohérentes peuvent provoquer des exceptions arithmétiques ou des allocations excessives. Les objectifs nuls ou négatifs, les nombres extrêmes et une progression supérieure à l’objectif doivent être écartés. Il faut conserver la séquence brute et rendre visibles les révisions au lieu de réécrire discrètement l’historique de la jauge.

En exploitation, le meilleur modèle n’est donc pas un pourcentage isolé mais une machine d’état. Elle enregistre la capacité négociée, la session authentifiée, la commande et son étiquette. Elle journalise chaque notification, ses inconnues et ses anomalies. Elle collecte séparément les données propres à la commande. Elle ne quitte l’état « en cours » qu’à la réception de la réponse finale portant la bonne étiquette.

Après un OK, il reste parfois une autre frontière. Le serveur atteste la réussite selon le contrat IMAP. Il n’atteste pas automatiquement l’indexation par un moteur d’archives, la convergence d’une réplication, l’application d’une conservation légale ou l’envoi d’un avis au client. Chaque système ajouté au récit réclame son propre reçu.

RFC 9585 rend une réalité partielle plus visible. Elle ne donne pas à cette visibilité une autorité universelle. Capacité, activité, mesure, achèvement, résultat et effet sont six couches qu’une interface élégante ne doit pas confondre.

Sources