Résumé

  • Les options de sélection de RFC 5258 déterminent quels noms entrent dans le résultat ; les options de retour enrichissent seulement les noms déjà retenus. Sans la requête, la liste perd son sens probatoire.
  • RECURSIVEMATCH autorise le retour d'un ancêtre qui ne satisfait pas lui-même le critère SUBSCRIBED, y compris avec \NonExistent, lorsque CHILDINFO indique qu'un descendant est la cause.

Une arborescence convaincante peut répondre à une question étroite

Dans un client de messagerie, une ligne indentée ressemble à un objet. Une flèche suggère qu'il existe des enfants ; un nom cliquable semble promettre qu'une sélection réussira. Cette grammaire visuelle est efficace, mais elle dépasse facilement ce que le serveur a réellement affirmé.

LIST-EXTENDED ne transmet pas une photographie neutre de toutes les boîtes. Il exécute une requête. Le nom de référence et les motifs définissent l'espace de comparaison ; les options de sélection déterminent l'appartenance au résultat ; les options de retour demandent des renseignements supplémentaires. L'identité authentifiée et l'instant de traitement délimitent encore la réponse.

Deux commandes adressées au même état serveur peuvent donc produire deux arbres différents sans contradiction. L'une cherche les noms abonnés. Une autre énumère les boîtes locales puis demande une annotation d'abonnement. Une troisième inclut des noms distants. Une quatrième fait remonter un ancêtre pour montrer où se trouve un descendant abonné.

Le registre défendable ne se limite jamais aux lignes affichées. Il conserve la génération des capacités annoncées, le serveur et la session, le principal authentifié, le nom de référence, les motifs bruts, leur interprétation canonique, toutes les options, l'étiquette de commande, les réponses non étiquetées et l'heure. Sinon, on garde une réponse après avoir jeté la question qui lui donnait son autorité.

Sélectionner un nom et décrire un nom sont deux pouvoirs différents

RFC 5258 place les options de sélection avant les paramètres principaux de LIST et les options de retour après les motifs. La disposition reflète une frontière fonctionnelle. Une option de sélection modifie les conditions d'admission. En règle générale, un nom doit correspondre à au moins un motif LIST canonique et satisfaire toutes les options de sélection. RECURSIVEMATCH introduit une exception explicitement circonscrite pour les parents.

Une option de retour ne peut pas admettre un nom supplémentaire. Elle demande uniquement des informations pour les noms déjà sélectionnés. Si un logiciel utilise une annotation comme filtre, son résultat répond à une autre question, même si l'écran semble raisonnable.

SUBSCRIBED montre pourquoi cette distinction doit rester visible. Employé comme option de sélection, il demande les noms abonnés plutôt que l'ensemble des boîtes existantes. Un nom peut rester abonné après la disparition de la boîte. Employé comme option de retour, SUBSCRIBED indique simplement l'état d'abonnement de chaque nom retenu par la sélection de base ; il ne réduit ni n'élargit l'ensemble.

La sélection SUBSCRIBED implique l'annotation correspondante, et les lignes choisies portent \Subscribed. Cette commodité ne permet pas d'effacer la provenance. Pour une migration, il faut savoir si l'abonnement a causé la présence de la ligne ou s'il a seulement été observé sur une ligne admise par ailleurs.

La même prudence interdit d'assimiler LIST (SUBSCRIBED) à LSUB. La forme étendue doit produire des attributs exacts avec leur sens ordinaire. LSUB conserve des comportements historiques particuliers. Les réunir sous une seule catégorie « dossiers abonnés » détruit précisément la différence que la nouvelle commande formalise.

Un ancêtre peut apparaître après avoir échoué au filtre

Imaginons que Foo/Baz soit abonné et que Foo ne le soit pas. Un motif limité au premier niveau ne voit pas le descendant ; une sélection SUBSCRIBED écarte le parent. Sans mécanisme supplémentaire, le client obtient un résultat vide et ne sait pas qu'un abonnement existe plus bas.

Avec RECURSIVEMATCH, le serveur peut renvoyer Foo accompagné de CHILDINFO (SUBSCRIBED). Le parent doit toujours correspondre au motif LIST canonique de la commande. En revanche, le descendant qui justifie sa présence n'a pas à correspondre à ce motif. La ligne signifie donc : un descendant satisfait le critère et cet ancêtre fournit son contexte. Elle ne signifie pas que le parent est abonné.

CHILDINFO est la pièce qui empêche ce glissement. Si le client ne garde que le nom, le nœud explicatif peut devenir une boîte abonnée dans son cache. Si chaque ligne visible reçoit automatiquement les actions SELECT, déplacement ou suppression, l'interface accorde à un élément de contexte des pouvoirs que le protocole n'a jamais attestés.

La validité de la commande renforce cette lecture. RECURSIVEMATCH ne peut pas être la seule option de sélection, ni être accompagné uniquement de REMOTE. Dans ces cas, le serveur doit répondre BAD. La récursion sert à expliquer la satisfaction d'un autre critère chez un descendant ; elle n'est pas un bouton général « donnez-moi tout l'arbre ».

L'ancêtre peut être un emplacement sans boîte

La syntaxe hiérarchique d'IMAP n'oblige pas tous les préfixes d'un nom à correspondre à une boîte existante. Customers/ABC peut exister sans boîte Customers. L'affichage de la trajectoire requiert pourtant parfois le nom parent.

RFC 5258 autorise alors une ligne parent avec \NonExistent et CHILDINFO (SUBSCRIBED). Les deux faits s'additionnent : ce nom ne désigne pas une boîte existante ; il est renvoyé parce qu'un descendant satisfait la sélection. \NonExistent implique aussi \NoSelect.

Un nom peut également être à la fois \Subscribed et \NonExistent. L'abonnement porte sur un nom, l'existence porte sur l'objet boîte. Une suppression peut laisser l'abonnement en place. Déduire l'existence de l'abonnement supprimerait le signal nécessaire pour détecter et nettoyer cet état résiduel.

La question n'est pas identique à celle de RFC 2342. NAMESPACE décrit l'organisation des espaces personnel, partagé et des autres utilisateurs ; il n'accorde ni existence ni droit d'accès. RFC 5258 ajoute une causalité de requête : même après une opération de découverte, une ligne peut provenir de l'état d'un descendant et non du sien. Il faut donc garder séparément la grammaire du nom et la raison de sélection.

CHILDINFO conserve une raison, pas un enfant

CHILDINFO énumère les critères de sélection qui ont fait remonter l'ancêtre et affirme qu'au moins un descendant y répond. Il ne nomme pas ce descendant. Il ne fige ni son existence, ni son nom, ni son accessibilité.

Entre la réponse LIST et une commande suivante, un autre acteur peut supprimer ou renommer la boîte enfant. Une règle d'accès peut changer. Le client doit donc accepter qu'une exploration immédiate ne retrouve aucun descendant qualifiant. CHILDINFO est un constat daté, pas une clé étrangère durable.

Le renseignement reste précieux dans une session où plusieurs LIST sont envoyés en pipeline. Les réponses LIST non étiquetées doivent être rattachées à la bonne question. Les critères CHILDINFO, les options de la requête et l'ordre de réception constituent ensemble la preuve de dépendance. Une simple étiquette finale ne restitue pas toute la signification métier de chaque ligne intermédiaire.

Le serveur devrait omettre un CHILDINFO redondant lorsqu'il renvoie aussi l'enfant correspondant. « Devrait » n'autorise cependant pas une inférence d'absence. Le client doit tolérer le doublon sans compter deux fois, et ne doit pas conclure qu'aucun descendant n'existe lorsque l'élément manque dans une réponse qui n'avait pas à le fournir.

Enfin, CHILDINFO n'est pas \HasChildren. Le premier explique pourquoi une sélection a fait apparaître un ancêtre. Le second décrit, pour la navigation, l'état des enfants accessibles. Cause de présence et indice de structure sont deux observations différentes.

La flèche d'ouverture dépend de l'utilisateur et du moment

L'option de retour CHILDREN permet de recevoir \HasChildren ou \HasNoChildren. L'objectif est pratique : un client peut dessiner une arborescence repliée sans télécharger immédiatement tous les niveaux. Mais l'optimisation ne transforme pas l'attribut en propriété éternelle.

Un serveur ne devrait pas annoncer \HasChildren si des enfants existent mais que l'utilisateur authentifié ne peut en atteindre aucun, même si ce calcul n'est pas toujours économique. Un attribut exact pendant le traitement peut devenir obsolète avant le clic suivant, à cause d'une suppression ou d'un changement d'ACL.

\HasNoChildren signifie qu'aucune boîte enfant n'est accessible au principal courant. Il ne dit pas qu'aucun enfant n'existe pour personne. Il diffère aussi de \NoInferiors, qui affirme l'absence d'enfants et l'impossibilité d'en créer. Convertir ces deux tokens en une propriété permanente « feuille » efface la différence entre visibilité présente et impossibilité structurelle.

Une cache prudente est donc indexée au moins par serveur, compte ou principal, génération d'espace de noms, nom de boîte, génération de politique d'accès et instant. L'interface traite la flèche comme une invitation à redécouvrir, non comme l'autorisation de supprimer des descendants mémorisés.

Les extensions enrichissent la projection sans la rendre souveraine

REMOTE est une option de sélection singulière : elle étend le domaine examiné aux boîtes distantes et locales, sans option de retour jumelle. Cette extension de population ne prouve toutefois ni l'accessibilité du serveur distant, ni le succès de SELECT, ni l'accès aux messages.

LIST-STATUS peut joindre des états, SPECIAL-USE des rôles, NOTIFY et CONTEXT des mécanismes de mise à jour. L'ACL de RFC 4314 maintient les droits séparés de la seule apparition d'un nom. Ces extensions rendent l'arbre plus riche ou plus réactif, pas indépendant de la requête, du principal et de la génération.

Les registres IANA fournissent les vocabulaires communs des capacités et attributs. Une inscription prouve l'existence d'un token et de sa référence normative. Elle ne prouve pas qu'un déploiement l'annonce, l'implémente correctement ou expose la même population. RFC 9051 modernise IMAP, mais ne remplace pas la preuve concrète de la commande exécutée.

La discipline des couches de réalité proposée par Lu Heng donne ici une règle de gestion simple. Le parent est réel comme élément d'un résultat. Le descendant est réel comme cause rapportée à un instant. La boîte, l'abonnement, le droit, la synchronisation et le nœud d'écran sont d'autres réalités. Une abstraction reste sûre tant que les jointures qui les relient demeurent réversibles.

Sources