Résumé

  • LANGUAGE sélectionne des textes humains et peut présenter une traduction des préfixes NAMESPACE ; cette présentation ne renomme ni la boîte partagée ni son espace canonique.
  • COMPARATOR sélectionne la règle de correspondance et d’ordre de SEARCH, SORT et THREAD ; un résultat n’est reproductible que si le décodage, la conversion, le comparateur et les replis ont été conservés.

Une préférence peut cacher plusieurs autorités

Une application de messagerie propose volontiers un seul réglage de langue. Ce geste semble pouvoir gouverner les menus, les noms de dossiers et la recherche. RFC 5255 ne lui accorde pas un pouvoir aussi large. Il sépare la langue des réponses humaines et les règles de comparaison, et permet aux serveurs d’annoncer ces extensions indépendamment.

LANGUAGE agit sur ce que le serveur explique. I18NLEVEL agit sur la façon dont certaines chaînes sont comparées. La première décision peut changer un message d’erreur ou la présentation d’un préfixe ; la seconde peut changer les messages trouvés, leur ordre ou leur groupement. Le contenu stocké peut rester parfaitement stable.

Le danger opérationnel apparaît lorsqu’un champ unique nommé « locale » absorbe ces responsabilités. Après un incident, personne ne sait si un dossier a été réellement renommé, si seule son étiquette a changé, si la requête a utilisé un autre comparateur ou si des données invalides sont passées dans un repli par octets.

La traduction de NAMESPACE doit rester réversible

RFC 5255 limite LANGUAGE aux chaînes fixes du serveur, notamment les textes de réponse et les représentations de préfixes NAMESPACE. Il précise qu’un alias localisé de boîte partagée relèverait d’un autre mécanisme. Une traduction affichée n’acquiert donc aucune autorité de nommage.

La réponse TRANSLATION associe une représentation locale au préfixe canonique. C’est au client de convertir entre les deux lorsqu’il affiche le nom d’une boîte. Cette responsabilité impose de conserver le lien dans les deux sens. Une interface qui mémorise uniquement le texte français peut prendre un changement de langue pour une création, une suppression ou un déplacement.

Les conséquences dépassent l’écran. Les favoris, caches, outils de migration, journaux d’accès et systèmes de droits peuvent reprendre ce qu’ils croient être un identifiant. La bonne unité de preuve associe texte présenté, préfixe canonique, langue sélectionnée, serveur et génération de session. Elle interdit à l’étiquette de devenir une clé silencieuse.

Les réponses LANGUAGE portent elles aussi une sémantique précise. Un seul tag indique la langue désormais active. Plusieurs tags constituent une énumération et ne changent pas la sélection. Un échec laisse en vigueur la langue précédente. L’interface doit distinguer sélection, inventaire et refus au lieu de cocher indistinctement la préférence demandée.

Même default n’est pas une identité stable. Il demande la préférence choisie par l’administrateur, éventuellement selon l’utilisateur actif. Le serveur décide alors d’une politique de présentation ; il ne déclare ni la langue essentielle de la personne ni un attribut durable de la boîte.

TLS coupe l’histoire de la préférence en deux

LANGUAGE est utilisable avant l’authentification, car un utilisateur peut devoir comprendre un avertissement de mot de passe expiré ou une erreur de sécurité. Mais cette disponibilité place la première négociation avant la protection du canal.

Un attaquant actif peut supprimer ou modifier cet échange et rendre les explications de STARTTLS ou d’authentification plus difficiles à interpréter. RFC 5255 exige donc que le client renvoie LANGUAGE après l’activation de TLS ou d’une couche de sécurité SASL.

Ce deuxième envoi n’est pas une répétition décorative. Il inaugure une nouvelle génération d’autorité. Le journal doit relier la sélection au moment exact où la protection est devenue active, à la réponse du serveur et à la première réponse humaine gouvernée par le nouveau choix.

La commande renouvelée ne rend pas le texte authentique par magie. Elle ne valide pas les identifiants et ne remplace pas les codes de réponse structurés. Elle établit seulement que la préférence appliquée aux opérations suivantes a été négociée dans le canal protégé. Code machine, explication humaine et état de sécurité restent trois réalités.

Le comparateur fait partie de la requête

Le comparateur par défaut s’applique en l’absence de négociation. Le comparateur actif est celui de la session. I18NLEVEL=1 impose i;unicode-casemap; I18NLEVEL=2 permet de demander le comparateur actif et d’en sélectionner un autre avec COMPARATOR.

Cette sélection modifie le sens exécutable de SEARCH. Elle vaut pour des champs définis — objet, corps, expéditeur, destinataire, en-têtes — et pour les clés pertinentes de SORT et certaines comparaisons de sujet dans THREAD. Elle ne normalise pas universellement tout ce qui est stocké.

Après l’authentification, le comparateur par défaut doit rester stable pour la connexion. Cette stabilité donne un contexte reproductible aux requêtes implicites. Une commande COMPARATOR explicite peut néanmoins changer la règle active ; il faut donc conserver la demande et la réponse, pas seulement la valeur finale.

Chaque commande exige aussi une opération adaptée. SEARCH utilise la sous-chaîne. SORT exige l’ordre, qui s’appuie sur l’égalité. Si le comparateur ne fournit pas l’opération, le serveur doit refuser la commande. L’activation réussie d’un comparateur ne prouve pas qu’il convient à tous les usages.

Avant de comparer, il faut déjà interpréter

Le texte n’arrive pas intact au comparateur. Le serveur retire les encodages MIME des en-têtes ou des corps, puis convertit le résultat vers le jeu de caractères attendu. Ces étapes possèdent leurs propres échecs et leurs propres zones laissées à l’implémentation.

Pour une recherche par sous-chaîne, un échec de conversion conduit à comparer les octets de la représentation décodée avec i;octet. Un résultat indéfini du comparateur peut déclencher le même repli. Pour un tri, les chaînes converties et valides sont ordonnées par le comparateur actif ; les autres sont regroupées séparément, ordonnées par octets, puis placées après le groupe valide.

La liste finale peut sembler uniforme alors que deux régimes l’ont produite. Une recherche peut retrouver une chaîne parce que les octets coïncident après l’échec de la comparaison linguistique. Une position basse peut exprimer un défaut de conversion plutôt qu’un rang sémantique.

Le reçu utile conserve donc l’encodage déclaré, le retrait MIME, la conversion, la validation, le comparateur demandé, le comparateur retenu, le repli, la génération du corpus et l’ensemble exact des résultats. La simple requête saisie par l’utilisateur ne suffit pas à rejouer la décision.

Le même corpus peut livrer deux vérités de session

Deux serveurs peuvent héberger les mêmes messages et proposer des comparateurs ou convertisseurs différents. Une mise à jour peut aussi changer une bibliothèque Unicode sans changer la base de messages. Les réponses divergent alors sans que l’un des corpus soit différent.

Ce n’est pas une permission d’être arbitraire. C’est une obligation de versionner le mécanisme. Un dossier d’incident disant « aucun résultat » doit pouvoir distinguer l’absence d’un message d’un échec de décodage, d’une conversion impossible, d’un comparateur inadapté ou d’un repli inattendu.

Le registre IANA des capacités IMAP cite encore LANGUAGE, I18NLEVEL=1 et I18NLEVEL=2. Il prouve le nom et la référence des capacités, pas leur déploiement, leur conformité ni la version de l’algorithme installée chez un opérateur.

Les travaux ultérieurs confirment la limite. RFC 6855 introduit la prise en charge UTF-8 de noms d’utilisateur, d’adresses, d’en-têtes et de noms de boîte. RFC 9051 remplace IMAP4rev1. Ces fonctions d’identité et de contenu dépassent les textes fixes localisés par RFC 5255.

Deux chaînes écrites dans le même alphabet peuvent donc relever d’autorités différentes : étiquette traduite, nom canonique, terme normalisé ou contenu stocké. Lu Heng fournit ici la discipline de direction : chaque couche est réelle, mais aucune ne certifie automatiquement l’autre. L’affichage doit revenir au nom canonique ; le résultat doit revenir à la génération de comparaison qui l’a produit.

Sources