Resumen
- RFC 5267 convierte una búsqueda o un ordenamiento en una base seguida por ADDTO y REMOVEFROM, operaciones sensibles a la posición que deben aplicarse en el orden recibido y que se identifican con la etiqueta del comando original.
- La especificación niega que exista una función de instantánea. NOUPDATE puede entregar una respuesta inicial sin seguimiento, mientras que CANCELUPDATE, un cambio de buzón seleccionado o una brecha no explicada terminan la continuidad.
Una interfaz rápida puede estar contando una historia vieja
El correo nuevo aparece sin recargar. Un mensaje deja de cumplir el filtro y desaparece. El contador se ajusta. El usuario ve una superficie fluida y la organización la llama «búsqueda en tiempo real». Ese nombre mezcla dos hechos distintos: que la interfaz reaccionó y que el cliente puede demostrar el estado completo.
Con RFC 5267, SEARCH, UID SEARCH, SORT o UID SORT puede pedir UPDATE. La respuesta inicial establece el punto de partida. Después, ESEARCH puede llegar de forma no solicitada con ADDTO y REMOVEFROM. Cada actualización incluye la correlación con la etiqueta del comando que originó el contexto. No es un aviso genérico sobre el buzón; es una instrucción para mantener aquella pregunta y aquel orden.
El texto aclara que no hay snapshot facility. CONTEXT apenas indica que probablemente se reutilizará el criterio. El servidor puede ignorarlo o emplearlo para un caché o índice, y su comportamiento visible debe ser idéntico. La garantía no es «el servidor conserva una foto para mí». La garantía demostrable es más exigente: «conservo la respuesta de origen y no he perdido ninguna transición válida».
El contexto es una réplica ordenada, no un conjunto de notificaciones
ADDTO lleva una posición y uno o más resultados que deben insertarse en el orden solicitado. REMOVEFROM lleva una posición y los resultados que salen desde ella. SEARCH y SORT expresan cambios con números de secuencia; sus variantes UID usan UIDs.
El cliente debe procesar cada elemento en el orden en que aparece, incluso si una respuesta ESEARCH contiene varios. El servidor debe producirlos de modo que esa aplicación secuencial conserve el orden pedido. Esto impide tratarlos como eventos conmutativos. Insertar y retirar en posiciones diferentes puede dar resultados incompatibles si dos consumidores los procesan en paralelo.
Por eso, el registro mínimo no es una tabla final de miembros. Debe contener el programa de búsqueda, el modo de identificador, el orden solicitado, la etiqueta, el resultado inicial y la secuencia exacta de recepción. Reordenar por marcas de tiempo locales no recompone la autoridad. Tampoco puede reutilizarse la misma etiqueta mientras el contexto sigue activo: el servidor debe responder BAD, porque esa etiqueta es el vínculo entre el cambio no solicitado y su pregunta.
EXISTS y EXPUNGE delimitan el significado de un número
Los números de secuencia son posiciones móviles. Cuando una entrega o un append incorpora mensajes, un ADDTO que use esos números debe enviarse después de EXISTS; antes de EXISTS, los números nuevos todavía no son válidos. Si una expulsión genera REMOVEFROM, la retirada debe aparecer antes de EXPUNGE, cuando la numeración anterior aún permite interpretar la operación.
El orden del cable es, por tanto, parte de la evidencia. EXISTS, FETCH, ESEARCH y EXPUNGE no pueden enviarse a archivos separados para unirlos después según el reloj de cada servicio. ESEARCH puede presentarse sin comando en curso, durante otro comando o mientras IDLE mantiene abierta la recepción. Un sistema de observabilidad que solo archiva solicitudes y respuestas etiquetadas deja fuera las transiciones que sostienen la lista.
Además, si el propio criterio contiene números de secuencia, estos se evalúan al recibir el comando. Una renumeración posterior no emite una actualización solo porque ahora la misma cifra apuntaría a otro mensaje. Volver a evaluar el texto numérico en el futuro sería ejecutar otra búsqueda.
NOUPDATE separa una respuesta válida de un servicio vivo
Un servidor puede negarse a mantener más contextos, por ejemplo al alcanzar un límite interno. Lo comunica con un NO no etiquetado, código NOUPDATE y la etiqueta afectada. Las demás opciones de retorno siguen siendo obligatorias.
Así puede llegar una respuesta útil y finalizar el comando, pero sin la continuidad solicitada. Si el cliente guarda las filas y descarta el NO, la interfaz conserva datos correctos para un instante y los presenta como si siguieran actualizándose. Es un error de estado, no necesariamente un error de búsqueda.
La norma exige al menos un contexto actualizable por cliente y recomienda más. También reconoce que mantener un ordenamiento puede costar más que mantener una búsqueda sin ordenar. El cliente puede intentar una variante más barata, volver a calcular o marcar el resultado como estático. Lo único indefendible es ocultar la negativa.
PARTIAL no convierte la pantalla en frontera del contexto
PARTIAL devuelve una ventana posicional. En una aplicación moderna encaja con listas virtuales y paginación. Sin embargo, UPDATE no se limita mediante otras opciones de retorno. La combinación UPDATE y PARTIAL puede notificar cambios fuera de la ventana visible. Lo mismo vale para COUNT, MIN o MAX: esos resúmenes no reducen el conjunto cuyos cambios se informan.
Si un componente descarta las actualizaciones que no afectan a sus filas presentes, las posiciones de una ventana futura dejan de tener fundamento. Puede optar por no mantener todo el contexto, pero entonces tiene que invalidarlo y pedir una nueva base. La vista es una proyección; no es la superficie que define la autoridad.
El flujo termina aunque la aplicación quiera continuidad
Las actualizaciones cesan al dejar de estar seleccionado el buzón o al emitir CANCELUPDATE para las etiquetas correspondientes. El servidor puede liberar los recursos. Reconectar, seleccionar de nuevo o repetir el criterio no reanuda la cadena anterior: crea otra observación.
Una caída de conexión es obvia. Más peligrosos son un error parcial del parser, una cola con backpressure que elimina un elemento o una reconexión automática que conserva el antiguo estado visual. Desde la primera transición posiblemente perdida, las que lleguen después no pueden certificar la lista. Un flujo posicional no se cura por continuar.
CONDSTORE y QRESYNC ofrecen mecanismos de resincronización bajo sus propias condiciones. IDLE facilita la llegada de respuestas no solicitadas. NOTIFY permite declarar interés en eventos. Ninguna capacidad vecina repara por mera presencia un transcript RFC 5267 incompleto. Hace falta ejecutar el procedimiento, verificarlo y establecer una nueva base.
La primacía del código en funcionamiento obliga a nombrar el objeto real: comando exacto, capacidades, selección de buzón, base, modificaciones seriadas y frontera de continuidad. El resultado inicial, la aceptación de UPDATE, la réplica reconstruida, la página visible y la decisión humana son capas diferentes. Si una fila no puede rastrearse hasta su etiqueta y su lugar en la secuencia causal, la organización posee una animación convincente, no evidencia del presente.
Fuentes
- RFC 5267: Contexts for IMAP4
- Registro de RFC 5267 en RFC Editor
- RFC 5267 en IETF Datatracker
- Búsqueda de erratas de RFC 5267
- RFC 3501: IMAP4rev1
- RFC 4731: extensión ESEARCH
- RFC 5256: SORT y THREAD
- RFC 2177: comando IDLE
- RFC 5465: extensión NOTIFY
- RFC 7162: CONDSTORE y QRESYNC
- RFC 5182: extensión SEARCHRES
- Registro IANA de capacidades IMAP
- Lu Heng: Running-Code Primacy
- Lu Heng: On Reality Layers
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
