Resumen

  • Un servidor puede rechazar UPDATE sin dejar de cumplir las demás opciones de una búsqueda. La respuesta final de éxito no convierte ese rechazo en aceptación.
  • Una ventana pequeña de resultados no delimita las notificaciones del conjunto completo ni demuestra que el trabajo permanente sea pequeño.
  • El producto debe mostrar si ha obtenido una respuesta, si dispone de seguimiento y cómo recuperará una vista útil cuando ese seguimiento no exista.

Un indicador de éxito puede estar midiendo exactamente lo que dice y, aun así, ocultar un problema para el usuario. Imaginemos una aplicación de correo cuya tasa de consultas completadas mejora. Los resultados aparecen deprisa y los errores terminales son escasos. Sin embargo, algunas listas que parecen mantenerse al día solo recibieron su contenido inicial.

No hace falta que la búsqueda esté averiada. Puede haberse cumplido una parte de la petición y rechazado otra. El servidor respondió a la pregunta sobre el buzón, pero no aceptó el trabajo adicional de comunicar los cambios futuros. La aplicación ha contado correctamente la primera prestación y ha dado por supuesta la segunda.

Este escenario es ilustrativo, no un incidente observado en un proveedor. Su mecanismo está descrito en RFC 5267, Contexts for IMAP4, publicado en julio de 2008. El cliente puede pedir actualizaciones de los resultados de una búsqueda o de una ordenación. Si el servidor rechaza la opción UPDATE, envía una respuesta NO sin etiqueta de comando, con el código NOUPDATE y la etiqueta de la búsqueda afectada como argumento.

Las demás opciones de retorno deben seguir cumpliéndose. Por eso la búsqueda puede terminar con éxito aunque no vaya a proporcionar actualizaciones. No son dos diagnósticos incompatibles: son decisiones sobre trabajos diferentes. El error aparece si la interfaz conserva el éxito y pierde el alcance del rechazo.

La obligación empieza donde termina la primera respuesta

Una consulta ordinaria tiene un trabajo identificable: evaluar unos criterios y devolver información. Mantener sus resultados exige además detectar qué cambios posteriores afectan a la selección, conservar lo necesario para interpretar esa relación y avisar al cliente.

La carga depende de la consulta y de la implementación. Una vista ordenada puede exigir más estado que una búsqueda sin ordenación adicional. La cantidad de mensajes que acaba viendo el usuario tampoco describe por sí sola cuánto cuesta sostener el conjunto.

RFC 5267 no concede una libertad ilimitada para rechazar. Exige al menos un contexto con actualización por cliente y recomienda ofrecer más. Ese mínimo no es una cuota universal de memoria, un compromiso de admitir cualquier número de vistas ni una tarifa de servicio. Es una obligación concreta dentro de la capacidad anunciada.

El texto reconoce que los contextos ordenados tienen un coste de implementación mayor. Rechazar la actualización de SORT no implica rechazar también un contexto SEARCH. Entre las respuestas que puede considerar el cliente figuran una búsqueda sin ordenación o la cancelación de otro contexto.

La elección requiere criterio de producto. Si el usuario trabaja según un orden, sustituirlo silenciosamente puede cambiar su tarea. Una alternativa más barata puede ser adecuada, pero no equivale a haber cumplido la solicitud original sin modificaciones. El sistema debe saber cuándo está ofreciendo otra prestación.

Una ventana no es una suscripción más pequeña

Los nombres de las opciones favorecen una simplificación engañosa. CONTEXT, UPDATE y PARTIAL no forman una única orden para crear una especie de caché paginada en directo.

CONTEXT expresa que probablemente se reutilizarán los criterios. El servidor puede atender esa indicación manteniendo resultados o un índice, pero también puede ignorarla. No crea una instantánea congelada. UPDATE puede solicitarse sin haber usado antes esa indicación.

UPDATE pide cambios en el conjunto que habría devuelto la búsqueda completa. Las incorporaciones y retiradas permiten mantenerlo. Pedir inicialmente COUNT no significa que cada aviso posterior traiga un nuevo total: el cliente puede calcularlo a partir de los cambios de pertenencia.

PARTIAL limita la parte de los resultados que se devuelve. No limita las actualizaciones a las filas visibles. Una aplicación puede mostrar una página y seguir recibiendo cambios relativos a todas las coincidencias. Hacer una pantalla más ligera no elimina automáticamente la obligación que mantiene al servidor pendiente de la búsqueda.

La extensión de 2023 RFC 9394 conserva expresamente ese alcance. Amplía los resultados parciales con posiciones contadas desde el final y añade un modificador para UID FETCH. La capacidad PARTIAL tampoco sustituye a CONTEXT=SEARCH: para combinar funciones hay que comprobar las capacidades pertinentes.

Hay otra diferencia reveladora. En las combinaciones descritas por esa extensión, SAVE y PARTIAL pueden guardar el subconjunto devuelto; si interviene COUNT, el conjunto guardado comprende todas las coincidencias. Una respuesta reducida puede coexistir con un conjunto semánticamente amplio. No permite calcular la memoria de un producto concreto, pero sí impide inferir el alcance del estado a partir del tamaño de la pantalla.

La separación importa para presupuestar. Transferencia inicial, estado conservado y trabajo ante cada cambio son partidas relacionadas, no idénticas. Optimizar una de ellas sin observar las otras puede desplazar el coste en lugar de reducirlo.

El rechazo tiene un destinatario preciso

NOUPDATE identifica la búsqueda cuya actualización se rechaza. Esa asociación permite que el cliente cambie el estado de la vista correspondiente, en vez de degradar todas las vistas o ninguna.

La decisión se produce durante la petición. No debe interpretarse como una cancelación general de los contextos previamente aceptados. Tampoco basta con anotarla en un registro si la aplicación sigue presentando el resultado como continuamente mantenido.

La etiqueta original conserva su utilidad después de que la búsqueda inicial termine. Los cambios posteriores se correlacionan con ella. RFC 5267 exige una respuesta BAD cuando una nueva búsqueda UPDATE reutiliza una etiqueta todavía ocupada por otra búsqueda actualizada.

Por tanto, la finalización del comando no agota siempre la vida de su identificador. Esto no transforma la etiqueta en una identidad empresarial permanente, una credencial o el nombre del buzón. Le atribuye una función limitada y necesaria: relacionar el trabajo futuro con la solicitud que lo originó.

Un sistema que libere mentalmente esa relación al recibir el primer éxito puede ser rápido y, a la vez, incapaz de explicar qué mantiene actualizado. La corrección del resultado inicial no compensa esa pérdida de contexto.

Los cambios mantienen una lista, no una historia completa

Cuando UPDATE sí ha sido admitido, el cliente debe procesar ADDTO y REMOVEFROM en el orden recibido, incluso cuando varios elementos aparecen dentro de una misma respuesta. El servidor debe producirlos de manera que se conserve el orden solicitado para el resultado.

Los números de secuencia de los mensajes añaden dependencias. Una incorporación debida a la llegada o adición de mensajes, expresada mediante esos números, debe seguir a EXISTS. Una retirada debida a la eliminación definitiva debe preceder a EXPUNGE. De otro modo, el significado del número puede cambiar antes de que el cliente aplique la operación correspondiente.

Estas reglas no convierten el mecanismo en un archivo durable de todos los acontecimientos del negocio. Una lista de mensajes pendientes representa una selección actual. No prueba quién decidió atender cada mensaje ni conserva por sí misma todos los cambios sucedidos durante una desconexión.

Las notificaciones deberían enviarse oportunamente, pero la especificación no fija una latencia universal en milisegundos. Una promesa comercial de frescura acotada requiere observación y decisiones adicionales. El número del RFC no demuestra que esa promesa se cumpla en una instalación.

El seguimiento también termina. Dejar de seleccionar el buzón acaba con sus actualizaciones; CANCELUPDATE puede detener las correspondientes a una o varias etiquetas originales. El servidor puede liberar recursos y el cliente puede buscar de nuevo. Reconstruir la lista actual es distinto de recuperar todas las transiciones perdidas.

La caché está al servicio de la semántica

El servidor puede guardar resultados aunque el cliente no haya usado CONTEXT. Pero debe comportarse de forma observable igual que si no existiera esa caché. Cuando cambia el buzón, los resultados conservados deben mantenerse adecuados o descartarse.

La libertad de implementación no es permiso para devolver información vieja con un significado nuevo. Tampoco convierte una optimización interna en una instantánea prometida al cliente. El servidor puede elegir cómo producir la respuesta, no redefinirla silenciosamente por conveniencia de almacenamiento.

RFC 5267 describe estrategias para reducir costes. En ciertos contextos sin ordenación, puede compararse el estado anterior y posterior de las marcas con el criterio de búsqueda. Una petición parcial puede recalcular resultados hasta alcanzar la ventana necesaria. Los contextos ordenados tienden a necesitar más resultados conservados; tras borrar mensajes, puede faltar información necesaria si no se guardó antes.

No se trata de mediciones de proveedores. Son ejemplos de intercambio entre cálculo, memoria y conocimiento previo. Eliminar una caché no demuestra haber eliminado el trabajo permanente, del mismo modo que conservarla no demuestra mantener correctamente su contenido.

Las extensiones posteriores no borran los límites

RFC 5465, The IMAP NOTIFY Extension, publicado en 2009, permite controlar de forma más amplia las notificaciones no solicitadas. Cuando el servidor ofrece además las capacidades de contexto pertinentes, amplía UPDATE para solicitar atributos FETCH al incorporarse un mensaje nuevo al conjunto.

Sus controles de carga deben distinguirse de NOUPDATE. Una solicitud NOTIFY demasiado costosa puede rechazarse inicialmente con una respuesta etiquetada NO y NOTIFICATIONOVERFLOW. Más tarde, si el servidor no puede o no quiere proporcionar el volumen requerido, puede desactivar notificaciones mediante un OK no etiquetado con ese código y comportarse como tras NOTIFY NONE. No se debe deducir de ello una cancelación universal de todos los contextos creados por otras funciones.

El registro de erratas de RFC 5465 contiene una corrección esencial para la continuidad. La errata técnica verificada 2318 invierte un ejemplo que consultaba el estado antes de organizar las notificaciones. Primero deben organizarse estas y después consultarse el estado, evitando un intervalo en el que un cambio podría pasar inadvertido.

Dos operaciones individualmente correctas no garantizan, por tanto, una transición correcta entre observación inicial y seguimiento. Esta evidencia corresponde al ejemplo del estándar, no a un fallo actual atribuido a una empresa.

La errata técnica 4833 sigue marcada como Reported. Señala exigencias contradictorias en dos secciones acerca del orden relativo de FETCH y ESEARCH. No establece una corrección definitiva. La referencia del remitente a un comportamiento desplegado es un testimonio histórico, no una comprobación contemporánea de interoperabilidad. Las erratas editoriales verificadas corrigen una palabra, paréntesis y una referencia de sección; no resuelven ese conflicto técnico.

Durante esta investigación, las consultas de erratas de RFC 5267 y RFC 9394 no devolvieron registros coincidentes. Eso describe las consultas, no certifica la ausencia de errores en implementaciones.

Una prestación que debe tener dueño

Los usuarios autorizados también pueden crear suficientes contextos para perjudicar el servicio. La autenticación no hace desaparecer el consumo. RFC 5267 contempla límites, registro de uso y estrategias de implementación para contenerlo.

Rechazar una obligación puede ser una decisión responsable. El problema es permitir que el rechazo desaparezca justo donde se formula la promesa al usuario. El servidor protege recursos, el cliente entrega la primera respuesta y alguien sigue creyendo que su trabajo está bajo observación continua.

El ensayo de Lu Heng sobre el problema de agencia ofrece una forma de ordenar esa responsabilidad: relacionar la autoridad para decidir con las consecuencias de la decisión. Aquí importan quienes prometen una vista actual, quienes admiten su coste permanente y quienes actúan sobre lo que esa vista muestra.

Su explicación del propósito de BTW también exige describir estructuras sin inventar culpables. No se ha probado ninguna cuenta de correo ni se ha medido la conducta de un proveedor en este informe. La conclusión es más limitada: una consulta correcta no paga ni acredita, por sí sola, el servicio necesario para mantener correcto su resultado.