Résumé

  • RFC 2062 a sorti les anciennes formes d’IMAP du protocole principal tout en conservant une carte de compatibilité pour les pairs plus âgés.
  • Un nouveau serveur n’était pas tenu d’accepter les anciennes commandes et ne devait généralement plus émettre les réponses retirées ; le client gardait certaines obligations de réception.
  • Comprendre une forme ancienne n’accordait donc pas au correspondant le droit de continuer à la produire indéfiniment.

Une migration réelle n’est presque jamais simultanée. Le serveur change, puis le client ; ou l’inverse. Entre les deux subsiste une période où le nouveau code doit savoir reconnaître le passé sans le choisir comme langage courant. Les huit pages de RFC 2062 organisent précisément cette période.

Le texte est Informational et ne se présente pas comme une norme Internet. Il rassemble des éléments de RFC 1176, des variantes IMAP2bis et de RFC 1730 après leur retrait du cœur d’IMAP4rev1. Ce geste documentaire est déjà une décision d’architecture : conserver la mémoire d’une grammaire n’oblige pas à lui conserver une place dans la production normale.

Les commandes retirées comprennent FIND ALL.MAILBOXES, FIND MAILBOXES, les formes SUBSCRIBE MAILBOX et UNSUBSCRIBE MAILBOX, ainsi que PARTIAL. Plusieurs anciens attributs FETCH sont également consignés. Le nouveau serveur n’est pas obligé de les prendre en charge. Il peut choisir cette compatibilité pour un ancien client, mais cette faveur ne transforme pas l’ancien dialecte en contrat courant.

Le cas de PARTIAL montre que la substitution n’est pas seulement cosmétique. La réponse FETCH ne précisait pas la plage rendue et plusieurs commandes pouvaient être exécutées hors ordre. Le client devait donc synchroniser chaque étape. Une fonction comparable dans une syntaxe plus récente pouvait fournir une relation plus explicite entre demande et reçu. Deux opérations proches ne produisent pas nécessairement la même preuve.

Pour les réponses, RFC 2062 est plus direct. Les nouveaux serveurs ne doivent généralement plus transmettre les réponses obsolètes. MAILBOX n’est admise que comme réponse aux anciennes commandes FIND. Le client doit ignorer l’ancienne réponse COPY et traiter l’ancienne réponse STORE comme FETCH. Accepter le passé peut ainsi signifier le parser sous condition, le neutraliser, ou le traduire vers une sémantique actuelle.

Cette tolérance ne vaut pas autorisation d’émettre. RFC 2683 avertira ensuite qu’un client ne doit pas envoyer une commande retirée simplement parce que certains serveurs permissifs la comprennent. RFC 2061 avait déjà séparé les conseils de compatibilité des exigences de base et recommandé de ne pas ressusciter certains espaces « bboard », même pour accueillir de vieux clients.

La même logique réapparaît dans l’évolution ultérieure. RFC 3501 garde RFC 2062 parmi ses références historiques. RFC 9051 rend la sélection entre IMAP4rev1 et IMAP4rev2 visible par les capacités et ENABLE IMAP4rev2. Lorsqu’un serveur annonce les deux versions, les formes supprimées ne réapparaissent normalement qu’en réponse à un comportement explicitement IMAP4rev1. Il s’agit d’une continuité de méthode, non d’une preuve de filiation causale.

Pour une équipe d’exploitation, un test de parsing réussi démontre seulement une capacité de réception. Il ne démontre ni la configuration de sortie, ni la demande du pair, ni les octets réellement transmis. Un tableau de bord réduit à « compatible ancien » confond quatre états : grammaire d’entrée, grammaire de sortie, mode négocié et observation du trafic.

Le retrait sûr commence donc par couper l’émission, puis mesure les réceptions résiduelles, isole les exceptions par pair et ne supprime le parseur qu’après disparition prouvée du besoin. Dans cet ordre, la compatibilité sert la transition. Dans l’ordre inverse, une concession de réception devient un prétexte pour que le passé gouverne encore la production.

Sources