Resumen

  • Las opciones de selección deciden qué nombres pertenecen al resultado; las opciones de retorno solo agregan datos a nombres ya seleccionados. La respuesta no es interpretable sin la pregunta exacta.
  • Con RECURSIVEMATCH, un ancestro puede entrar por la coincidencia de un descendiente, llevar \NonExistent y no estar suscrito; CHILDINFO conserva esa causalidad limitada en el tiempo.

Lo que parece un catálogo puede ser contexto de navegación

Las interfaces han enseñado a leer una jerarquía como un censo. Cada fila parece una cosa, la sangría parece una relación estable y el triángulo de expansión parece una afirmación sobre la existencia de hijos. Ese lenguaje visual funciona precisamente porque oculta la consulta que lo produjo.

LIST-EXTENDED hace explícita esa consulta. El nombre de referencia y los patrones delimitan el espacio de coincidencia. Las opciones de selección eligen miembros. Las opciones de retorno solicitan atributos para esos miembros. El usuario autenticado y el instante de procesamiento acotan todavía más la observación.

Por eso un mismo estado del servidor admite respuestas distintas y correctas. Se puede preguntar por nombres suscritos; seleccionar todos los buzones locales y marcar después cuáles están suscritos; ampliar el universo a nombres remotos; o pedir que aparezca un padre para no perder de vista a un descendiente que cumple el filtro.

Una bitácora que solo guarda la tabla final ya ha borrado la mitad de la evidencia. Debe conservar generación de capacidades, servidor, sesión, principal, nombre de referencia, patrones originales y canónicos, opciones de selección y retorno, etiqueta de comando, todas las respuestas sin etiqueta y tiempo. La fila obtiene autoridad de ese recibo, no de su posición en una pantalla.

Pertenencia y descripción no son intercambiables

Una opción de selección modifica qué nombres puede devolver la operación. Salvo reglas especiales, el nombre debe coincidir con al menos un patrón LIST canónico y satisfacer todas las condiciones seleccionadas. RECURSIVEMATCH es una excepción normativa para ancestros, no una licencia para relajar cualquier filtro.

Una opción de retorno modifica la información que acompaña a cada nombre ya coincidente. No puede sumar nombres al conjunto. Si una implementación deja que una anotación cambie la membresía, o trata un filtro como si fuera una etiqueta, ha respondido a otra pregunta aunque la salida siga pareciendo un árbol normal.

SUBSCRIBED ocupa ambos espacios y revela el peligro. Como opción de selección pide nombres suscritos en lugar de buzones existentes. El conjunto puede excluir buzones reales y puede incluir un nombre cuya caja ya desapareció. Como opción de retorno, SUBSCRIBED se limita a indicar el estado de suscripción de nombres elegidos por la LIST subyacente. No filtra ni crea miembros.

La selección SUBSCRIBED implica su retorno, de modo que las filas traen \Subscribed. Pero el recibo aún debe distinguir causa y atributo. En una migración importa saber si una fila fue admitida por la suscripción o si la suscripción fue solamente un dato observado sobre una fila admitida por otro criterio.

LIST (SUBSCRIBED) tampoco equivale a LSUB. La operación extendida exige atributos completos y exactos con su significado ordinario; LSUB arrastra significados históricos especiales. Normalizar ambas respuestas en una misma colección de “carpetas suscritas” elimina la razón por la que RFC 5258 estableció una alternativa.

La coincidencia puede estar un nivel más abajo

Supongamos que Foo/Baz está suscrito y Foo no. Un patrón que solo alcance el primer nivel no incluye al hijo. La condición SUBSCRIBED rechaza al padre. Sin otra señal, una aplicación puede obtener una lista vacía y ocultar un destino relevante.

RECURSIVEMATCH permite devolver Foo junto con CHILDINFO (SUBSCRIBED). El padre todavía debe coincidir con el patrón LIST canónico de la solicitud. El descendiente causal no tiene que coincidir con ese patrón. El mensaje preciso es que existe, o existía al procesar la orden, al menos un descendiente que satisfizo el criterio; el ancestro solo aporta contexto.

Nada en esa respuesta convierte al padre en suscrito. Si el cliente descarta CHILDINFO y persiste solo el nombre, una explicación se vuelve un hecho directo. Si después habilita SELECT o acciones destructivas para todas las filas visibles, entrega facultades de buzón a un nodo que el servidor solo usó para mostrar una ruta.

El propio protocolo prohíbe RECURSIVEMATCH solo o acompañado únicamente de REMOTE. El servidor debe responder BAD. La opción necesita otro criterio cuya satisfacción recursiva pueda explicar. No significa “recorrer el árbol entero”.

Un prefijo de nombre no garantiza un buzón

La jerarquía textual de IMAP puede saltarse niveles materiales. Puede existir Customers/ABC sin un buzón Customers. Aun así, una interfaz necesita el prefijo para situar al hijo. RFC 5258 permite que la respuesta del padre lleve \NonExistent y CHILDINFO (SUBSCRIBED).

No hay contradicción. \NonExistent afirma que el nombre no designa un buzón existente e implica \NoSelect. CHILDINFO afirma que el nombre fue devuelto porque un descendiente satisfizo la selección. Son hechos aditivos sobre capas diferentes.

También son compatibles \Subscribed y \NonExistent. La suscripción puede sobrevivir a la eliminación del buzón. Un sistema que deduce existencia a partir de suscripción borra el residuo que una herramienta de saneamiento necesita detectar.

RFC 2342 trata un límite vecino: NAMESPACE explica la gramática de los nombres personales, compartidos y de otros usuarios, sin demostrar existencia o acceso. La cuestión de RFC 5258 es posterior y más concreta. Incluso una consulta de descubrimiento ejecutada puede devolver una fila debido a un descendiente. La estructura nominal y la causalidad de selección requieren recibos distintos.

CHILDINFO no identifica al descendiente

CHILDINFO enumera las condiciones que hicieron aparecer al ancestro y asegura que al menos un descendiente las cumplió. No proporciona el nombre del hijo. Tampoco congela el estado hasta la próxima orden.

Un buzón puede ser borrado o renombrado entre la respuesta LIST y la exploración. Un ACL puede retirar acceso. La especificación obliga al cliente a tolerar que la comprobación posterior no encuentre ningún descendiente coincidente. La causa registrada es válida para el instante original, no una referencia permanente.

Esta causa sirve además para atribuir respuestas cuando varias LIST están en curso. Las respuestas no etiquetadas llegan dentro de una secuencia y pueden necesitar el criterio CHILDINFO, las opciones emitidas y el orden de recepción para unirse a su comando. Guardar solo el resultado etiquetado final deja huérfanas las filas intermedias.

Un servidor debería omitir CHILDINFO redundante cuando también devuelve al hijo coincidente. Esa recomendación no es una garantía de ausencia. El cliente debe tolerar el dato redundante sin duplicar objetos y no puede inferir que no hay descendientes simplemente porque CHILDINFO falte en un contexto donde no era exigible.

CHILDINFO tampoco sustituye a \HasChildren. Uno explica por qué la selección incluyó un ancestro. El otro describe si hay hijos accesibles para apoyar la navegación. Mezclarlos borra la diferencia entre procedencia causal y estado de presentación.

La flecha de expansión pertenece a una sesión de acceso

Con la opción CHILDREN, el servidor puede añadir \HasChildren o \HasNoChildren. El cliente evita así descargar una jerarquía completa para decidir dónde dibujar controles de expansión. La ventaja de rendimiento crea una tentación: guardar ese control como si fuera una propiedad absoluta del buzón.

La semántica es más limitada. El servidor no debería usar \HasChildren cuando existen hijos pero ninguno es accesible al usuario actual, aunque calcularlo pueda ser costoso. Y una respuesta correcta puede quedar anticuada segundos después por eliminación, renombrado o cambio de derechos.

\HasNoChildren expresa que no hay buzones hijo accesibles al principal autenticado. No dice que no existan para otros. Tampoco es \NoInferiors, que afirma que no existen inferiores y que no se pueden crear en el futuro. Una interfaz que convierte ambos en “hoja permanente” transforma una observación de visibilidad en una imposibilidad estructural.

La clave de caché segura incluye servidor, cuenta o principal, generación del espacio de nombres, nombre, generación de política de acceso y hora. La expansión debe seguir siendo una acción de descubrimiento renovable, no una autorización para borrar descendientes almacenados o declarar vacío global.

Más metadatos no convierten la proyección en custodia

REMOTE amplía la selección para considerar buzones remotos y locales. No tiene una opción de retorno equivalente. Ese aumento del universo operativo no demuestra que el destino remoto sea alcanzable, que SELECT vaya a funcionar o que haya acceso a mensajes.

LIST-STATUS añade información de estado; SPECIAL-USE, funciones; NOTIFY y CONTEXT, mecanismos de actualización. RFC 4314 mantiene separados los derechos ACL. El árbol puede ser más expresivo y estar más actualizado, pero continúa atado a una solicitud, un principal y una generación.

Los registros de IANA establecen nombres comunes para capacidades y atributos. Su existencia demuestra una referencia normativa, no la publicidad o corrección de una instalación concreta. RFC 9051 transporta estas ideas al IMAP moderno, sin reemplazar la pregunta probatoria: qué comando exacto corrió, bajo qué identidad y por qué apareció cada fila.

La disciplina de capas de realidad de Lu Heng ayuda a fijar la responsabilidad. El ancestro es real como elemento de una respuesta. El hijo es real como causa observada. Buzón, suscripción, derecho, sincronización y nodo renderizado son realidades separadas. La abstracción es confiable mientras se pueda volver de la pantalla al recibo y del recibo a comprobaciones independientes.

Fuentes