Кратко

  • draft-ietf-core-conditional-attributes-14 позволяет ограничивать частоту вычисления условий с помощью c.epmin и c.epmax; это задаёт границы между проверками, а не непрерывное наблюдение физического сигнала.
  • Отсутствие уведомления становится доказательством только после раздельной проверки поддержки параметров, источника и частоты выборки, вычисления триггера, планирования отправки, пути через прокси, получения приложением и фактического результата.

Событие длиной в один интервал

Представим клапан, чьё давление обычно держится ниже заданного порога. Клиент регистрирует условное наблюдение и разрешает серверу вычислять условия не чаще установленного периода. Сразу после одной проверки давление подскакивает выше границы, а перед следующей возвращается к норме. В выборке сервера обе соседние точки безопасны.

Ни одна потерянная дейтаграмма здесь не нужна. Условие ни разу не стало истинным в момент вычисления, поэтому серверу нечего было отправлять. Поток может соблюдать все заявленные правила и всё же не содержать события, которое имело физическое значение. Фраза «тревог не было» описывает проекцию, а не историю ресурса.

Редакция 14 документа Conditional Query Parameters for CoAP Observe опубликована 14 сентября 2026 года и истекает 18 марта 2027 года. Это активный Internet-Draft рабочей группы CoRE с предполагаемым статусом Standards Track. В Datatracker по-прежнему отмечено, что после вопроса на Working Group Last Call требуется новая редакция. Это не RFC, не статистика внедрения и не сертификат конкретной реализации.

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

Условия выбирают историю

c.gt и c.lt ищут переход выше или ниже границы относительно последнего сообщённого значения. c.st реагирует на заданный шаг, c.band формирует режим «внутри» или «вне» полосы, а c.edge выбирает направление логического перехода.

Каждый параметр создаёт свой рассказ о ресурсе. После пересечения c.gt дальнейший рост выше порога обычно не порождает цепочку одинаковых тревог. Для c.st сравнение идёт с последним сообщённым значением, хотя между двумя сообщениями ресурс мог пройти много состояний. Если несколько условий выполняются вместе, приоритетов нет: сервер выдаёт одно уведомление и обновляет последнюю сообщённую величину и время.

Следовательно, одно сообщение может быть результатом нескольких фактов, а ноль сообщений — результатом отсутствия подходящего отсчёта, а не отсутствия физического движения. Восстановить непрерывную кривую по этой записи нельзя.

Поддержка может исчезнуть без ошибки

Маркер обнаружения if="core.conditional" сообщает лишь общую возможность и остаётся необязательным. Он не гарантирует поддержку конкретного параметра, а его отсутствие не исключает поддержку. Точного механизма объявления каждого условия документ не задаёт.

Ещё важнее правило для синтаксически корректного, но неподдерживаемого параметра. Сервер должен считать его не имеющим эффекта и продолжить наблюдение; отклонять запрос только по этой причине нельзя. Поэтому 2.05 Content и Observe Option подтверждают отношение наблюдения, но не полный набор активных условий.

Неверный тип, неположительный период или невозможное соотношение минимумов и максимумов — другая ситуация, для которой предусмотрен 4.00 Bad Request. Есть и третий исход: если слишком малые c.pmax или c.epmax создают неприемлемый риск усиления трафика, сервер может обработать GET, но не зарегистрировать наблюдателя. Об этом говорит отсутствие Observe Option, а не сам класс успешного ответа.

Выборка, вычисление и отправка — разные часы

c.epmin сообщает, что клиент не заинтересован в более частом вычислении условия. c.epmax ограничивает максимальный интервал до следующего вычисления и требует проверить условие по его истечении. Но проверка всё равно дискретна. Между двумя такими моментами ресурс способен пересечь границу и вернуться.

c.pmin управляет уже частотой уведомлений. Триггер может возникнуть, когда отправка ещё запрещена, а сервер за этот период может сохранить только последний отсчёт. c.pmax просит присылать сообщение не реже заданного предела даже при неизменном значении, однако равные c.pmin и c.pmax не образуют жёсткого контракта реального времени: планирование остаётся Best Effort.

Таким образом, у физического процесса есть собственная шкала времени; у сенсора — моменты выборки; у сервера — моменты вычисления; у очереди — допустимое время отправки; у клиента — время получения. Одна отметка в уведомлении не может одновременно доказать все пять.

Прокси создаёт ещё одну границу

CoAP Observe допускает кэши и прокси. Редакция 14 предупреждает: когда представление не меняется, прокси способен помешать клиенту получить периодическое обновление c.pmax. В качестве смягчения предлагается Max-Age не больше c.pmax. Поэтому запись сервера об отправке не равна квитанции клиента.

Параметр c.con=true требует Confirmable-уведомление и позволяет получить подтверждение в механизме надёжности CoAP. ACK относится к обмену сообщениями. Он не доказывает непрерывную выборку, обнаружение каждого краткого выброса, обработку полезной нагрузки приложением или срабатывание исполнительного механизма.

Токены связывают запросы и ответы, значения Observe помогают упорядочить уведомления, OSCORE защищает обмен в пределах своего контекста. Это важные протокольные факты, но ни один из них не заполняет пробел между двумя измерениями.

Отмена тоже требует точной проекции

Условное наблюдение связано с полным URI. Для явной отмены клиент должен повторить исходные условные параметры вместе с сигналом отмены. /pressure?c.gt=8 и /pressure?c.gt=10 — разные проекции, хотя ресурс один.

Удаление строки из интерфейса не доказывает, что старый наблюдатель исчез. Надёжная квитанция отмены включает конечную точку, токен, полный URI проекции и закрывающий ответ. Иначе забытая регистрация может продолжать тратить энергию или посылать данные, которым уже нет видимого получателя.

Какие квитанции нужны для вывода «выброса не было»

Надёжная цепочка разделяет восемь этапов:

  1. Какой ресурс и какая эпоха сервера объявили условную возможность, если она вообще объявлялась?
  2. Какой URI, токен и Observe Option установили нужную проекцию?
  3. Какие именно параметры сервер фактически поддерживал?
  4. Откуда бралась выборка, какова её точность и когда выполнялось условие?
  5. Какой порог, диапазон, фронт или шаг сравнивался с каким последним сообщённым значением?
  6. Как c.pmin, c.pmax, объединение условий и Best Effort определили отправку?
  7. Прошло ли конкретное уведомление через кэш и прокси к нужному клиенту?
  8. Обработало ли его приложение и произошёл ли требуемый физический или деловой результат?

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

Границы источников

Зафиксированные документы подтверждают предложенную семантику параметров, оговорку Best Effort, правило неподдерживаемого параметра, предупреждение о прокси и способ отказа от регистрации. Они не подтверждают распространённость технологии, свойства названного продукта, реальный инцидент, уровень безопасности или юридическое обязательство. Документ об усилении трафика сам является истёкшим IRTF-драфтом; он объясняет модель риска, а не доказывает атаку.

В терминах Heng Lu протокольная запись заслуживает ровно тот вес, который позволяет её происхождение. Сервер имеет право сообщить, что проверил выбранный отсчёт и решил отправить уведомление. Он не получает от этого полномочий утверждать, что между отсчётами ничего не происходило. Такой вывод требует другой измерительной системы и собственного набора доказательств.

Источники