Кратко

  • Действующий Internet-Draft о SCHClet предлагает автономные функции SCHC для одного Stratum и одной Instance, из которых можно убрать управление правилами и ставшие неявными заголовки.
  • Разбор RuleID не завершает доказательство совместимости. Нужны общая SCHClet Configuration у двух сторон, наблюдение пути для неподходящего ввода, проверка реконструкции и результат верхнего уровня.

RuleID совпал. Декодер выбрал правило. Это событие синтаксического разбора, а не квитанция о доставленном смысле. Целевые значения могли различаться, один конец мог обновить набор правил, а восстановленный пакет — не пройти проверку безопасности или обработку приложением. Между первым совпадением и полезным результатом остаётся вся цепочка реальности.

Проект SCHClet, редакция 01, опубликован 29 сентября 2026 года. Это активный Internet-Draft рабочей группы SCHC, предназначенный для Standards Track, но ещё не RFC, отчёт о реализации, испытании совместимости или внедрении. Он предлагает выделить одну функцию или подмножество SCHC в самостоятельный компонент для одного Stratum и одной SCHC Instance.

SCHClet может заниматься только компрессией, одним режимом фрагментации либо ограниченным набором операторов и действий. Параметры могут быть постоянными; управление правилами можно удалить или оставить правила только для чтения. Проект связывает такой выбор с сокращением кода, памяти, вычислений и энергии. Это архитектурные ожидания, а не опубликованный замер гарантированной экономии.

В минимальном примере Version, Traffic Class и Flow Label для IPv6 считаются равными 6, 0 и 0. Четыре байта заменяются восьмибитным RuleID. Значения 0x60 и 0xFF намеренно расходуют больше битов ради простого кода. Цель примера — не предельная экономия канала, а ограниченная и предсказуемая функция.

Исключённые значения по-прежнему нужны при восстановлении. Они хранятся в общей конфигурации. Разрабатываемая архитектура SCHC различает Stratum, Instance и Discriminator. SCHClet для одного известного контекста может полностью исключить соответствующий заголовок. Получатель дополняет смысл заранее известными данными. Если знания двух сторон разошлись, короткий пакет может не содержать признака, который объяснит расхождение.

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

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

RFC 8724 уже строит SCHC на общих контексте и правилах. RFC 9011 показывает профиль с фиксированными решениями для LoRaWAN. RFC 9441 демонстрирует развитие дополнительной функции. SCHClet не устраняет контекст, а упаковывает узкую функцию для повторного применения. Чем меньше исполняемая поверхность, тем важнее точная идентичность конфигурации, которая задаёт её смысл.

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

Отсюда не следует, что каждому SCHClet нужен центральный контроллер или динамическое согласование. Заводская настройка может быть правильной для действительно неизменной пары, а двусторонняя процедура — достаточной в ограниченном домене. Но выбранный способ поддержания общего состояния фактически выполняет часть протокола, хотя его байтов нет в каждом пакете.

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

Источники