SPECIFICATION

Глава 1. Обзор и позиционирование

В настоящей главе определяются область применения протокола DTP (§1.1), позиционирование протокола (§1.2), связь с CAP (§1.3), цели проектирования (§1.4), модель Master-Slave (§1.5) и уровни соответствия (§1.6), а в §1.7 «Управление версиями и совместимость» приводятся правила управления версиями DTP в нормативной форме — благодаря чему настоящий протокол несёт собственное описание версий, позволяя стандартным реализаторам обращаться к нему напрямую без поиска внешних документов.

1.1 Область применения протокола

Data Tunnel Protocol (DTP) SHALL быть протоколом прикладного уровня, отвечающим за двунаправленную передачу данных между терминальными устройствами и экземплярами Fay в рамках экосистемы iFay.

DTP MUST реализовывать следующие два основных потока данных:

Сбор данных (Data Collection): от терминала (Slave) к Fay (Master); используется для сохранения данных, произведённых терминалом, в Personal Data Heap iFay.
Инжекция данных (Data Injection): от Fay (Master) к терминалу (Slave); используется для временного предоставления терминальным приложениям минимизированного набора данных, отфильтрованного iFay.

DTP MUST NOT использоваться для других целей.

1.2 Позиционирование протокола

DTP MUST работать как протокол прикладного уровня поверх существующих транспортных протоколов, включая, но не ограничиваясь BLE, RTSP, WebSocket и TCP.

DTP MUST взаимодействовать с конкретными транспортными протоколами через слой абстракции Transport_Adapter (см. раздел 3.4). Ядро DTP MUST NOT зависеть от деталей реализации какого-либо конкретного транспортного протокола.

1.3 Связь с CAP

DTP MUST работать совместно с Control Authorization Protocol (CAP) и следовать следующему разделению обязанностей:

CAP отвечает за авторизацию подключения, аутентификацию личности и обмен ключами.
DTP отвечает за передачу потока данных на основе переговоров.

Реализация DTP MUST начинать передачу данных только после того, как CAP завершил аутентификацию и обмен ключами. Если CAP не готов, реализация DTP MUST отказаться от отправки данных и вернуть ошибку KEY_NOT_READY (код ошибки 2002, см. главу 9).

1.4 Цели проектирования

Реализация DTP MUST удовлетворять следующим целям проектирования:

Цель	Нормативное требование
Транспортная независимость	Основная логика DTP MUST быть отделена от любого конкретного транспортного протокола
Переговоры в первую очередь	Любая передача данных MUST осуществляться на основе установленного Agreement
Суверенитет данных	Master MUST удерживать окончательное право принятия решения по потокам данных
Сквозное шифрование	Payload MUST передаваться в зашифрованном виде
Сохранение контекста	Каждый Fragment MUST содержать структурированные метаданные контекста
Возможность возобновления	Реализация MUST поддерживать возобновление на основе порядковых номеров

1.5 Модель Master-Slave

DTP MUST различать следующие две роли:

Master: физическое лицо или Fay (iFay / coFay). MUST обладать правом инициировать сбор данных и правом принимать решение о приёме инжекции данных.
Slave: программный или аппаратный терминал. MAY инициировать только запросы на инжекцию данных; MUST NOT инициировать запросы на сбор данных.

Реализация DTP MUST обеспечивать соблюдение следующих ограничений:

В любой момент времени один Slave MUST NOT управляться более чем одним Fay (Controller).
Controller MAY приглашать другие Fay в качестве Observer.
Observer MUST NOT инициировать запросы или изменять Agreement; они MUST получать только копии потоков данных, доступные только для чтения.
Когда Master инициирует запрос на сбор данных, Slave SHOULD принять его. Slave MAY отказаться, но отказ MUST сопровождаться обоснованием, связанным с соответствием требованиям (см. раздел 5.3.1).
Когда Slave инициирует запрос на инжекцию данных, Master MUST обладать полным правом принятия решения и MAY принять, отклонить или предложить альтернативу.

1.6 Уровни соответствия

Реализация MUST объявить свой уровень соответствия:

Полное соответствие (Full Conformance): реализация удовлетворяет всем правилам MUST и SHOULD.
Базовое соответствие (Core Conformance): реализация удовлетворяет всем правилам MUST, но MAY не удовлетворять некоторым правилам SHOULD.
Несоответствие (Non-Conformance): реализация не удовлетворяет какому-либо правилу MUST. Реализация, претендующая на статус DTP, MUST NOT находиться в этом состоянии.

1.7 Управление версиями и совместимость (Version Management & Compatibility)

Настоящий раздел является нормативным (Normative). Настоящий раздел является единственным авторитетным источником (Single Source of Truth) для правил управления версиями DTP. Везде, где правила версий упоминаются в других местах основного текста (включая главу 10 «Управление версиями» и журнал изменений, если таковой имеется), эти упоминания MUST следовать настоящему разделу и MUST NOT переопределять установленные здесь правила.

Настоящий раздел организован в следующем фиксированном порядке: три ортогональные оси версий (§1.7.1) → семантика MAJOR.MINOR и классификация изменений (§1.7.2) → правила согласования версий и совместимости (§1.7.3) → редакционная редакция и errata (§1.7.4) → таблица размещения номера версии и контрольный список для реализаторов (§1.7.5).

1.7.1 Три ортогональные оси версий

Информация о версии DTP MUST управляться вдоль трёх взаимно ортогональных осей. Эти три оси MUST NOT объединяться в единый номер версии; каждая ось имеет своё пространство значений, место записи и правило развития, и изменение по одной оси MUST NOT вынуждать изменение по двум другим (наблюдаемое определение ортогональности).

Ось	Значение	Пространство значений	Место записи	Входит в проводной формат?
Версия протокола (Protocol Version)	Контракт взаимодействия	`dtp/MAJOR.MINOR` (два уровня, без PATCH; `MAJOR` и `MINOR` — неотрицательные целые числа)	Поле `protocolVersion` заголовка фрейма, имя файла schema	Да
Статус документа (Document Status)	Жизненный цикл документа	Перечисление `Draft / Final / Deprecated / Obsolete` (ровно одно значение в любой момент)	Поле `status` во front matter	Нет
Редакционная редакция (Editorial Edition)	Errata и уточнения	Привязанная к дате публикации `YYYY-MM-DD` (например, `2025-10-25`)	Поле `date` во front matter и имя каталога публикации	Нет

Ключевые ограничения по статусу документа и каталогам (полные соглашения о каталогах и поток управления финализацией находятся в главе 10, привязанные к правилам настоящего раздела):

Статус документа MUST быть маркером front matter и MUST NOT кодироваться в пути к файлу или имени каталога.
Является ли опубликованная редакция в настоящее время Final, Deprecated или Obsolete, определяется исключительно полем status её файлов и MUST NOT выводиться из имени каталога.

1.7.2 Семантика `MAJOR.MINOR` и классификация изменений

MAJOR (мажорная версия)

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

изменение семантики авторитетного поля schema;
удаление сообщения или кода ошибки;
переопределение кода ошибки;
изменение поглощающего состояния (absorbing state) конечного автомата.

WHEN происходит изменение, нарушающее взаимодействие, MAJOR MUST увеличиваться на 1, а MINOR MUST сбрасываться в 0.

Взаимодействие НЕ гарантируется между различными версиями MAJOR.

MINOR (минорная версия)

MINOR используется для обратно совместимых дополнений, включая, но не ограничиваясь: добавление необязательных полей, добавление сообщений, добавление кодов ошибок, добавление параметров, добавление атрибутов. Критерий решения: пир, строго реализующий старую версию MAJOR.0, не отверг бы и не истолковал бы неверно новое сообщение.

WHEN происходит обратно совместимое дополнение, MINOR MUST увеличиваться на 1, а MAJOR MUST оставаться неизменным. В пределах одного MAJOR более высокий MINOR MUST быть обратно совместимым вплоть до MAJOR.0.

Правило классификации изменений (упорядоченное, разрешимое)

Для любого изменения его размещение MUST классифицироваться в следующем порядке, давая единственный уровень:

Если пир, строго реализующий старую версию MAJOR.0, отверг бы или неверно истолковал новое сообщение → классифицировать как MAJOR;
Иначе, если изменение добавляет видимое в проводном формате содержимое (заголовок/сообщение/код ошибки/параметр или иную видимую на проводе структуру) → классифицировать как MINOR;
Иначе (изменение только текста, без изменения проводного формата) → НЕ изменять версию протокола; использовать редакционную редакцию вместо этого (см. §1.7.4).
Если изменение одновременно соответствует нескольким уровням, MUST выбираться более высокий уровень.

1.7.3 Правила согласования версий и совместимости

Настоящий подраздел является нормативным.

Ограничения проводного формата

Только MAJOR.MINOR версии протокола входит в проводной формат (то есть поле protocolVersion заголовка фрейма и имя файла schema).
Версия протокола MUST всегда входить в проводной формат; реализация MUST NOT предоставлять какую-либо конфигурацию, исключающую версию протокола из проводного формата.
Статус документа и редакционная редакция MUST NOT входить в проводной формат. Реализация MUST NOT изменять поведение обработки сообщений на основании статуса документа или редакционной редакции — то есть два сообщения, идентичные в проводном формате, MUST NOT давать различающиеся результаты обработки из-за различающихся значений по этим двум осям.
IF в полученном сообщении в проводном формате отсутствует информация о версии протокола (в заголовке отсутствует protocolVersion, или отсутствует подполе major / minor, или его значение не является неотрицательным целым числом), THEN реализация MUST отвергнуть сообщение с ошибкой протокола и MUST NOT обрабатывать его под версией по умолчанию или предполагаемой версией.

Правила согласования

WHEN выполняется рукопожатие или начальная загрузка (bootstrap), обе стороны MUST каждая объявить свой набор поддерживаемых версий протокола, который MUST NOT быть пустым.
Выбор версии MUST следовать: сначала взять наивысший MAJOR, поддерживаемый обеими сторонами совместно, затем взять наивысший MINOR, поддерживаемый совместно в рамках этого MAJOR.
Сторона с более высоким MINOR MUST быть способна обслуживать пира с более низким MINOR: она MUST обрабатывать сообщения пира с семантикой более низкой версии, объявленной пиром, и MUST NOT отвергать лишь потому, что MINOR пира ниже.
IF обе стороны не разделяют ни одного общего MAJOR, THEN реализация MUST отвергнуть напрямую с ошибкой протокола и MUST NOT выполнять понижение версии по принципу наилучших усилий (best-effort). (Конкретная привязка этой ошибки — VERSION_INCOMPATIBLE / 7001 в главе 10.)
WHEN получено сообщение с тем же MAJOR, но более высоким MINOR, реализация MUST интерпретировать известные поля с семантикой собственного наивысшего MINOR и игнорировать нераспознанные необязательные поля; она MUST NOT отвергать, отбрасывать или генерировать ошибку.

Учётные данные и наборы шифров

WHEN выполняется поэтапное (rolling) обновление версии, реализация MUST сохранять действительными существующие, не истёкшие учётные данные или токены (credentials / tokens) и MUST NOT аннулировать их лишь из-за смены версии.
WHERE протокол уже имеет механизм согласования набора шифров (cipher-suite), согласование версий MUST повторно использовать тот же подход (каждая объявляет, берётся общий наивысший).

Последовательность согласования (Hello / Hello_Ack) и механизм «единая версия в пределах сессии, без переключения в середине сессии» находятся в главе 10.

1.7.4 Редакционная редакция и errata

Ограничения настоящего подраздела являются ненормативными (Non-normative) ограничениями управления; однако правило «MUST NOT маскировать под обновление» обязательно для корректности номера версии протокола.

WHEN после финализации выполняются чисто текстовые errata (исправление опечаток, добавление примеров, уточнение формулировок, починка ссылок), номер версии протокола (MAJOR.MINOR) MUST оставаться неизменным; errata MUST размещаться в новом каталоге даты публикации, а существующие опубликованные каталоги MUST оставаться замороженными, чтобы старые ссылки и линки MUST NOT нарушались.
Редакционная редакция SHOULD регистрироваться под категорией Editorial в журнале изменений (если таковой имеется); front matter MUST помечать её редакцию полями edition / date.
Редакционная редакция только разрешает ненормативные изменения и MUST NOT затрагивать семантику проводного формата, нормативные утверждения, коды ошибок, конечный автомат или поведение взаимодействия.
Жёсткое ограничение: IF изменение затрагивает семантику проводного формата, THEN оно MUST увеличить MINOR или MAJOR согласно §1.7.2 и MUST NOT маскироваться под выпуск errata (редакционную редакцию).

1.7.5 Таблица размещения номера версии и контрольный список для реализаторов

Таблица размещения

Точка размещения	Что размещается	Нормативное ограничение
Поле `protocolVersion` проводного конверта	`MAJOR.MINOR`	Несёт только `MAJOR.MINOR`, никакого другого уровня
Имя файла schema	Следует за `MAJOR.MINOR`	MUST NOT переименовываться с редакционной редакцией (сохраняет стабильность ссылок)
content-type	`application/dtp`	Идентифицирует семейство протоколов; его параметр `version=` — лишь удобство маршрутизации шлюза и НЕ является семантикой проводного формата
`status` / `date` во front matter	Маркеры управления документом	НЕ входят в проводной формат
git tag	`dtp-v<MAJOR.MINOR>-<статус>`	Тег MUST покрывать тело + тестовые векторы + schema вместе

Контрольный список для реализаторов (обязательно к прочтению)

Судить о взаимодействии только по версии протокола (MAJOR.MINOR); MUST NOT полагаться на статус документа или редакционную редакцию.
Один и тот же MAJOR MUST быть обратно совместимым вплоть до MAJOR.0.
MUST NOT трактовать errata (редакционные редакции) как обновления протокола.
MUST NOT полагаться на имя файла schema для кодирования редакционной редакции.
В период Draft НЕТ обещания совместимости.

Полные соглашения о каталогах и статусах, а также стандартные действия финализации (Draft → Final) находятся в главе 10 «Эволюция протокола и управление»; упоминаемые там формат git tag, перечисление статусов и определение редакционной редакции MUST быть привязаны к настоящему разделу (§1.7).