Кратко

  • Если сервер не может найти аннотации конкретного ящика, RFC 9590 позволяет не отправлять соответствующий METADATA и всё же завершить LIST ответом OK.
  • Явный NIL, пропущенный ответ, имя \NonExistent и родитель, показанный только ради подходящего потомка, — разные состояния доказательств, хотя интерфейс может показать один пустой значок.

Клиент запрашивает ящики верхнего уровня и аннотацию цвета для каждого из них. Приходят имена, несколько цветов, затем A01 OK List completed. Задача становится зелёной. Но у одного имени цвета нет.

Из этого нельзя вывести, что цвет «не задан». Сервер мог явно вернуть NIL, мог не выполнить поиск, мог перечислить несуществующий узел иерархии либо родителя, появившегося только из-за условия для потомка. Финальный тег закрывает команду, но не выбирает одну из этих причин.

Что именно объединяет расширение

Возможность LIST-METADATA добавляет METADATA как опцию возврата LIST-EXTENDED. Клиент может получить имена, атрибуты LIST и выбранные аннотации одной командой, не посылая GETMETADATA отдельно для каждого результата.

Для каждого доступного к перечислению ящика, соответствующего каноническому шаблону и опциям выбора, сервер обязан вернуть LIST, а затем один или несколько METADATA. RFC 5464 разрешает объединять несколько пар «запись–значение» или делить их между ответами. Значит, полноту собирают по паре «ящик–запись», а не по числу строк.

Если же сервер не может найти аннотации ящика, RFC 9590 допускает пропуск его METADATA. Итоговый OK всё ещё возможен. Это квитанция о завершении команды, а не сертификат заполнения всех локальных результатов.

Четыре пустоты

NIL — явный результат. RFC 5464 определяет его как отсутствие значения у записи. В примере RFC 9590 цвет foo не установлен, поэтому METADATA содержит NIL. На вопрос получен ответ.

При пропуске из-за невозможности поиска ответа нет. Подставить NIL означало бы приписать серверу неотправленное утверждение.

\NonExistent, согласно RFC 5258, означает, что имя не ссылается на существующий ящик, и подразумевает \NoSelect. Имя всё же может появиться как элемент иерархии или подписки. RFC 9590 показывает его без METADATA.

При SUBSCRIBED RECURSIVEMATCH родитель может быть возвращён только потому, что критериям соответствует потомок. Если сам родитель выбору не соответствует, METADATA для него не ожидается. Это граница выборки, не отказ поиска.

Полнота требует правильного знаменателя

Знаменатель — не все строки LIST. Сначала определяют ящики, соответствующие шаблону, выбору и цели запроса, затем составляют пары с запрошенными записями. Конкретные значения и явные NIL входят в наблюдаемую часть. Контекстные родители учитываются отдельно, а пропущенные допустимые пары не исчезают.

Для воспроизводимости нужны тег команды, шаблон, опции, перечень записей, имена и атрибуты LIST, ожидаемые пары, полученные значения, NIL, пробелы, повторные попытки, эпоха сеанса и действие с кэшем. Иначе слово «синхронизировано» станет символическим толкованием узкого OK.

RFC 5258 также предупреждает: потомка могут удалить или переименовать после LIST, но до доступа клиента. Результат привязан ко времени. RFC 9051 не превращает конец команды в доказательство отображения или человеческого внимания.

Реестр стандартизует имя, не эксплуатацию

IANA регистрирует LIST-METADATA и опцию METADATA. Это доказывает наличие общего словаря, но не внедрение, соответствие продукта или частоту отказов.

Принцип работающего кода ограничивает исполнимое утверждение реально отправленными байтами и разобранными парами. Минимальная общая спецификация задаёт их смысл. Число повторов, срок кэша, показ неизвестного и порог принятия остаются локальными решениями, а не скрытым содержанием OK.

Источники