Summary

  • INPROGRESS es una señal no etiquetada que puede comunicar avance, una cantidad aún indeterminada de trabajo o un simple latido para que la conexión no expire.
  • El comando concluye con una respuesta etiquetada OK, NO o BAD. Sus datos de salida y sus efectos fuera de IMAP siguen necesitando comprobantes propios.

Hay una decisión peligrosa escondida en casi toda barra de progreso: en qué momento deja de informar y empieza a autorizar. Si muestra 999 de 1.000, una persona puede asumir que solo falta un mensaje. Un proceso automático puede reservar capacidad, borrar un origen o avisar a otro sistema.

Para RFC 9585, esa lectura es excesiva. El servidor puede modificar la meta, retroceder el contador o descubrir otra fase de trabajo. También puede terminar con NO o BAD. El número describe el recorrido que el servidor eligió exponer; no promete la forma ni la existencia del resultado.

La extensión nació de una necesidad concreta. Un comando IMAP sobre un buzón grande puede tardar lo suficiente como para que el cliente confunda cómputo con abandono. Los servidores ya podían enviar texto libre, pero una frase destinada a los ojos de una persona no permite una reacción interoperable. Desde mayo de 2024, RFC 9585 ofrece un código reconocible por máquinas.

El primer dato es la capacidad. El servidor debe incluir INPROGRESS cuando responde a CAPABILITY si implementa la extensión. Eso confirma que conoce el mecanismo. No obliga a emitir una actualización en cada operación: si el comando termina pronto, puede no haber ninguna.

El segundo dato es la mera presencia. El servidor puede mandar el código solo para evitar que el cliente cierre la sesión por tiempo de espera. Cuando opta por notificar, la recomendación es hacerlo cada diez o quince segundos. La variante mínima no incluye detalles; la etiqueta, el avance y la meta se interpretan como NIL.

Solo la variante completa permite construir una barra. CMD-TAG procura identificar el comando; PROGRESS indica cuántos elementos se han procesado y GOAL, si se conoce, ofrece el total esperado tras completar la operación. Cuando no existe una unidad natural, se admite usar una escala porcentual con meta 100 y valores hasta 99.

La propia norma enumera las grietas. Si no se conoce el avance, también debe omitirse la meta. Si el total es incierto, GOAL queda en NIL. Si no se dispone de la etiqueta, o la etiqueta original contiene ], CMD-TAG será NIL. Una sesión con un único comando puede aprovechar ese latido anónimo; una sesión con varios ya no puede atribuirlo sin ambigüedad.

Tampoco existe una garantía de monotonicidad. Se recomienda que el avance crezca y que la meta permanezca fija, pero el cliente debe aceptar cambios. La interpretación sugerida es que el servidor alcanzó una meta anterior y descubrió más trabajo de larga duración. No es una explicación forense del comportamiento de cada producto. Es una regla para que el cliente no se rompa ante una realidad que cambió.

La separación decisiva viene de IMAP4rev2. Las respuestas no etiquetadas empiezan por * y transportan datos o estados que no concluyen un comando. La respuesta final reutiliza la etiqueta de la petición y declara OK, NO o BAD. Por eso INPROGRESS aparece dentro de un OK no etiquetado y tiene prohibido aparecer en una respuesta etiquetada.

La palabra OK puede confundir a quien ignore esa sintaxis. Un * OK [INPROGRESS ...] no es el A001 OK que cierra el comando A001. El asterisco mantiene la operación abierta; la etiqueta la clausura. Automatizar sin conservar esa diferencia convierte una señal de cortesía en una orden que el protocolo nunca emitió.

Incluso la clausura no reemplaza los datos. En el ejemplo SEARCH, las actualizaciones registran elementos procesados. Luego una respuesta SEARCH entrega los identificadores que coinciden. Finalmente llega el OK etiquetado. La meta no es el número de coincidencias, el contador no es la lista de mensajes y el cierre exitoso no contiene por sí solo el resultado.

RFC 9585 lo dice de forma expresa: los valores no son autoritativos fuera de la evaluación del progreso. Un cliente no puede usar GOAL para saber cuántos mensajes hay en una carpeta en lugar de la salida correcta de SEARCH. Para COPY ocurre algo similar: recorrer unidades no prueba cuántas quedaron persistidas en el destino ni si un índice, una réplica o una retención externa las reconoció.

La ausencia de señal tampoco resuelve la incertidumbre. Antes del primer aviso, el cliente debe asumir avance cero y meta desconocida. Esa convención evita inventar datos; no permite concluir que el servidor esté parado. Un comando rápido puede completarse sin aviso, mientras un servidor malicioso o averiado podría seguir enviando latidos sin producir un resultado útil.

La defensa empieza por no confiar en la aritmética recibida. La sección de seguridad exige descartar valores capaces de provocar excepciones: metas nulas o negativas, magnitudes extremas o un avance superior a la meta. La interfaz debe conservar revisiones y retrocesos como hechos observables, no suavizarlos hasta fabricar una historia lineal.

En una implementación operable, cada comando tiene un expediente. Incluye conexión, identidad de sesión, capacidad anunciada, etiqueta, momento de envío y comandos concurrentes. A ese expediente se agregan todas las notificaciones sin mezclar sus cifras con la salida funcional. Solo la respuesta etiquetada cambia el estado a éxito, fallo o error. Después se comprueba el estado externo cuando la decisión lo exige.

Esta última comprobación evita otra inflación. Un OK etiquetado certifica que el servidor IMAP declaró exitosa la operación según el protocolo. No prueba automáticamente que una canalización de archivo indexó los objetos, que una réplica convergió o que se cumplió una obligación jurídica. La autoridad no viaja gratis de un sistema al siguiente.

La virtud de RFC 9585 consiste en hacer visible una capa sin apropiarse de las demás. Actividad, medida, conclusión, contenido y efecto pueden estar relacionados; no son equivalentes.

Sources