Resumen

  • RFC 9590 permite omitir la respuesta METADATA de un buzón cuando el servidor no puede consultar sus anotaciones, sin impedir que LIST termine con OK.
  • Un valor NIL, una respuesta omitida, un nombre \NonExistent y un padre incluido solo para mostrar descendientes son hechos distintos, aunque una pantalla los pinte todos como un hueco.

Supongamos que una aplicación solicita los buzones superiores y la anotación que determina su color. Llegan los nombres, varios colores y la línea final A01 OK List completed. El trabajo figura como completado. Sin embargo, no hay color para uno de los nombres.

Marcar ese hueco como “sin configurar” sería una conjetura. También podría faltar la consulta, tratarse de un contenedor sin buzón real o ser un nombre devuelto por la lógica recursiva, no por cumplir la selección. El valor de RFC 9590 está en que permite separar esas posibilidades si el cliente conserva la evidencia.

Una sola orden, varios recibos

La capacidad LIST-METADATA incorpora METADATA como opción de retorno de LIST-EXTENDED. En vez de enumerar buzones y enviar después un GETMETADATA por cada uno, el cliente puede pedir nombres, atributos y anotaciones dentro de una sola operación.

Por cada buzón listable que coincida con el patrón canónico y con las opciones de selección, el servidor debe emitir LIST y después una o más respuestas METADATA. RFC 5464 permite repartir las entradas entre varias respuestas. Por eso, contar líneas no basta: el estado se ensambla por nombre de buzón y nombre de entrada.

RFC 9590 añade una excepción operacional explícita. Si el servidor no puede buscar las anotaciones de un buzón, puede descartar la respuesta METADATA correspondiente. Aun entonces, LIST puede devolver OK. El protocolo afirma que la orden concluyó; no afirma que la matriz de resultados esté llena.

Lo que parece vacío

NIL no es ausencia de transporte. RFC 5464 lo define como una entrada sin valor. En el ejemplo de RFC 9590, el color de foo vuelve expresamente como NIL porque no se ha establecido. Existe un recibo para la pareja buzón–entrada.

Cuando el servidor omite METADATA por no poder hacer la consulta, no existe ese recibo. Convertir la omisión en NIL inventaría una respuesta.

Un nombre con \NonExistent ocupa otra categoría. RFC 5258 indica que no se refiere a un buzón existente e implica \NoSelect, aunque el nombre puede aparecer por su función jerárquica. El ejemplo de RFC 9590 devuelve bar de ese modo y no adjunta METADATA.

La cuarta situación surge con SUBSCRIBED RECURSIVEMATCH: un padre puede incluirse porque conduce a descendientes que sí satisfacen la selección, aunque él mismo no la cumpla. La falta de METADATA responde entonces al perímetro elegido.

Estas diferencias son pequeñas en la sintaxis y enormes en una auditoría. Una describe un valor explícitamente inexistente; otra, evidencia no obtenida; otra, un nombre sin buzón; la última, contexto de recorrido.

Medir cobertura exige definir la población

El denominador correcto no es el total de líneas LIST. Es el conjunto de buzones que encajan en el patrón, satisfacen las opciones de selección y son objetivos de las entradas solicitadas, multiplicado por esas entradas. El numerador incluye valores concretos y NIL explícitos. Los padres meramente contextuales se clasifican fuera; las omisiones de objetivos elegibles permanecen visibles.

El registro mínimo debería conservar etiqueta de orden, patrón, opciones, entradas solicitadas, nombres y atributos LIST, parejas esperadas, parejas observadas, NIL, omisiones, reintentos, época de sesión y decisión de caché. Así puede explicarse después por qué un indicador fue verde o parcial.

Además, RFC 5258 advierte que un descendiente puede borrarse o renombrarse tras LIST y antes de que el cliente lo abra. La respuesta es una observación delimitada, no una fotografía eterna. RFC 9051 tampoco convierte el fin de una orden en prueba de que la interfaz mostró algo o de que una persona lo vio.

Estándar no significa resultado desplegado

IANA registra LIST-METADATA y la opción METADATA. Eso estabiliza nombres y referencias para la interoperabilidad. No demuestra cuántos servidores los implementan ni si una implementación concreta es correcta.

La primacía del código operativo obliga a formular el hecho ejecutable: qué bytes se emitieron, qué atributos contenían y qué parejas pudo reconstruir el cliente. La especificación común fija esa gramática. El reintento, la caducidad, el tratamiento de desconocidos y la política de presentación son decisiones locales. Llamarlas “lo que garantiza OK” confundiría una señal simbólica de éxito con la realidad que puede verificarse.

Fuentes