Кратко

  • В редакции 05 проекта JMAP Object Metadata от 28 октября появилось значение Binary: ровно два поля, @type и корректная строка base64 с заполнением. Сервер хранит и возвращает правильное значение в точности; неверный формат отклоняется.
  • Значение считается нулевой глубины, но путь запроса или патча не проходит через него. Текстовый фильтр не сопоставляет его содержимое. В редакции 04 такой конструкции ещё не было.

Наличие видно, отпечаток внутри — нет

Авторы приводят пример: в пространстве имён поставщика лежит 32-байтовый отпечаток. Запрос на наличие поля может его обнаружить. Поиск по последовательности байтов внутри отпечатка результата не даст — текстовые условия работают со строками, а Binary для них неделим. Попытка поправить только поле base64 также отвергается. Для обновления нужно заменить всё значение.

Новый пункт решает техническую задачу: строка JSON несёт текст Unicode, а приложениям иногда нужны произвольные байты. Проект допускает лишь два поля и base64 с обязательным заполнением; нарушение даёт invalidProperties. Путь внутрь оболочки даёт invalidPatch. Сервер обязан бережно вернуть запись, но смысл её содержимого задаёт не сервер.

Смысл определяет владелец пространства имён. Поставщик может назвать его своим доменом в нижнем регистре, без предварительной регистрации имени в IANA. Сервер решает, разрешать ли такие пространства для данного типа объектов и сколько места им выделять. Права на общие метаданные следуют праву читать объект; личные метаданные принадлежат соответствующему пользователю. Эти правила доступа уже были в прежней редакции. Новизна версии 05 — именно запечатанные байты.

Нулевая глубина не освобождает от платы за объём. Глубина ограничивает вложенность, а квота и предел размера регулируются отдельно. Проект предлагает серверам контролировать объём метаданных; превышение вызывает overQuota. Даже обычные текстовые фильтры сервер вправе отклонить как unsupportedFilter, если их поддержка слишком дорога. Покупателю «поиска по метаданным» нужны тип каждого поля, перечень работающих фильтров и метод подсчёта места.

Карточка IETF показывает рабочий Internet-Draft, а не готовый стандарт. Проверка конкретного сервера должна зафиксировать запись, побайтовое чтение, результат попытки поиска внутри оболочки и списание квоты. Правила стеклянной ячейки уже написаны; её работу надо увидеть.

Источники: редакция 05; редакция 04; статус IETF.