Summary

  • RFC 9590 can end an extended LIST command with tagged OK even when the server was unable to look up annotations for a mailbox and omitted its METADATA response.
  • Explicit NIL, an omitted response, a \NonExistent hierarchy name and a name returned only because descendants matched are different evidence states; a reliable client must not flatten them into “blank”.

Imagine a mailbox-inventory job that asks for every top-level mailbox and its display colour. The server returns the names, several colours and A01 OK List completed. The job records success. On the next screen, one colour is absent.

Was the colour deliberately unset? Did the annotation lookup fail? Was the returned name only a structural parent? Did it name no existing mailbox at all? A command counter cannot answer. RFC 9590 was not vague on this point. The problem appears only when an operator asks one receipt to prove more than the protocol assigned to it.

What the extension actually joins

Before RFC 9590, a client commonly listed mailboxes and then sent a GETMETADATA command for each mailbox. The new LIST-METADATA capability adds METADATA as a LIST-EXTENDED return option. One command can request mailbox names, LIST attributes and selected annotation entries.

For every listable mailbox that matches both the canonical LIST pattern and the selection options, the server must emit a LIST response followed by one or more METADATA responses for the requested annotations. “One or more” matters. RFC 5464 allows a server to put several entry/value pairs into one METADATA response or split them across several responses. The record to assemble is therefore keyed by mailbox and entry, not by response-line count.

The economy is real: fewer round trips and no compulsory GETMETADATA loop. But aggregation changes the observability problem. A single final tag closes a command carrying many independently meaningful results.

Four empty-looking cells

RFC 9590's examples provide a small taxonomy that monitoring software should preserve.

First, NIL is an explicit value state. RFC 5464 says an annotation value may be NIL, meaning it has no value. In RFC 9590's colour example, the mailbox foo receives a METADATA response whose requested colour is NIL because that annotation has not been set. The server answered the entry question.

Second, a response may be absent because the server was unable to look up annotations for an otherwise eligible mailbox. RFC 9590 permits the server to drop the corresponding METADATA response and still return tagged OK. No explicit NIL was observed. The evidence is incomplete.

Third, RFC 5258 permits a LIST response bearing \NonExistent. The name does not refer to an existing mailbox and the attribute implies \NoSelect; the name can still be useful in a hierarchy, for example because it has children. RFC 9590 shows such a name without a METADATA response. That is not the same as a failed lookup on an existing eligible mailbox.

Fourth, RECURSIVEMATCH can cause a parent name to be returned because a descendant satisfies the selection criteria even when the parent itself does not. RFC 9590's second example returns such a parent without metadata. Again, absence is expected from selection semantics, not evidence of an unset annotation.

The user interface may render all four as an empty decoration. The audit record cannot.

The denominator comes before the percentage

A meaningful coverage measure begins with the eligible set: names that match the canonical pattern, satisfy the selection options and represent the mailbox targets for which metadata is required. It then expands that set by the requested entry names. The numerator is the set of observed entry/value pairs, including explicit NIL. A LIST line included only as recursive context does not silently enlarge the denominator; a missing response for an eligible target does not silently disappear from it.

This is more demanding than counting commands, LIST lines or METADATA lines. It also respects split responses. If a client requested three entries and received two response lines carrying all three pairs, coverage may be complete. If it received one response containing only one pair, a green tagged completion does not invent the other two.

An operator should retain the command tag, pattern, selection options, requested entries, returned LIST names and attributes, expected mailbox-entry pairs, observed values, explicit NILs, omissions, retry results, session or collection epoch and cache action. That record makes later claims reproducible. Without it, “metadata synchronized” is only a label attached to an OK token.

Success has a narrow jurisdiction

Tagged OK means the LIST command completed under the protocol. It does not mean every optional or separately emitted datum exists. It does not say a cached annotation is fresh, a retry succeeded, a client rendered the result, or a user saw the intended mailbox treatment.

The same discipline applies to the IANA registries. LIST-METADATA is a standardized capability and METADATA is a registered LIST-EXTENDED return option with intended usage COMMON. Those entries make the wire vocabulary interoperable. They do not measure adoption, conformance or failure rates.

This is the practical force of running-code primacy. The executable fact is the set of bytes the server emitted and the client successfully interpreted. The standard gives those bytes common meaning; it does not authorize a dashboard to promote command completion into inventory completeness. Minimum initial specification leaves retry budgets, freshness windows, cache policy and presentation local. Those choices must be named as choices.

Sources