Resumen

  • RFC 2062 sacó la sintaxis IMAP antigua del documento principal sin borrar el mapa necesario para tratar con implementaciones anteriores.
  • Los servidores nuevos no tenían que admitir comandos obsoletos y, por regla general, no debían emitir respuestas retiradas; los clientes conservaban conductas de recepción concretas.
  • Ser capaz de aceptar una forma vieja no convertía su envío continuado en una práctica autorizada.

Las dos mitades de una conexión rara vez se actualizan el mismo día. Durante un tiempo, el sistema nuevo recibe mensajes de un pasado que ya no debería reproducir. RFC 2062 convirtió esa situación incómoda en una frontera técnica comprensible.

El memorando era Informational y declaró que no definía un estándar de Internet. Reunió elementos procedentes de RFC 1176, de variantes experimentales IMAP2bis y de RFC 1730 después de que IMAP4rev1 los retirara del cuerpo central. La documentación sobrevivía; la autoridad para usarla como lenguaje corriente, no.

Entre las órdenes antiguas estaban FIND ALL.MAILBOXES, FIND MAILBOXES, SUBSCRIBE MAILBOX, UNSUBSCRIBE MAILBOX y PARTIAL. También aparecían atributos FETCH como BODY[0] y varios nombres RFC822. RFC 2062 no obligaba a un servidor nuevo a implementarlos. El soporte podía ofrecerse para un cliente antiguo, como una excepción de interoperabilidad.

PARTIAL enseña por qué una retirada puede mejorar algo más que la estética. La respuesta se enviaba como FETCH sin indicar el intervalo devuelto. Como varias órdenes podían ejecutarse fuera de orden, no era seguro encadenarlas y unir los fragmentos sin sincronizar cada paso. La sustitución posterior podía cumplir una función parecida y, aun así, producir una evidencia mejor sobre la posición de los datos.

Las respuestas obsoletas recibieron reglas distintas. Un servidor nuevo no debía enviarlas, salvo el MAILBOX asociado a las viejas órdenes FIND. El cliente tenía que ignorar el COPY experimental por mensaje y tratar el antiguo STORE como FETCH. La recepción compatible no era aceptación ciega: a veces significaba analizar, a veces descartar y a veces normalizar.

Nada de ello daba al cliente licencia para seguir hablando el dialecto retirado. RFC 2683 advirtió expresamente que la permisividad de algunos servidores no volvía válido el envío de comandos obsoletos. RFC 2061 también había separado la compatibilidad opcional de las exigencias del protocolo y recomendaba no reimplantar ciertos comandos de tablones de anuncios ni siquiera en servidores atentos a clientes viejos.

Las revisiones posteriores mantuvieron la dirección. RFC 3501 citó RFC 2062 como historia. RFC 9051 utilizó capacidades y ENABLE IMAP4rev2 para hacer visible el modo elegido; un servidor que anuncia ambas revisiones normalmente no devuelve formas eliminadas salvo cuando el cliente IMAP4rev1 pide el comportamiento correspondiente. Es un paralelismo de diseño, no una afirmación de causalidad.

La lección operativa es separar pruebas. Que un analizador acepte una cadena demuestra capacidad de entrada, no selección de salida. Que un servidor tolere FIND no demuestra que el cliente deba enviarlo. Que aparezca una capacidad en IANA no demuestra adopción ni bytes observados.

Una retirada verificable conserva cuatro registros: gramática recibida, gramática emitida, modo negociado y tráfico realmente visto. Primero se corta la emisión antigua; después se miden las recepciones, se limitan las excepciones a pares identificados y, por último, se elimina el analizador cuando ya no queda necesidad probada. Así la compatibilidad facilita la salida en vez de conceder al legado un mandato permanente.

Fuentes