Спецификация Data Tunnel Protocol (DTP)
Версия: Draft Целевая версия: 2025-10-25 Статус: Черновик, ожидает рецензирования Уровень протокола: прикладной уровень
Введение
Настоящая спецификация определяет формат на проводе (wire format), конечный автомат, механизм переговоров, требования к шифрованию, обработку ошибок и правила управления версиями протокола Data Tunnel Protocol (DTP). DTP — это протокол прикладного уровня, используемый в экосистеме iFay для двунаправленного сбора и инжекции данных между терминальными устройствами и Fay.
Настоящая спецификация является нормативным документом DTP. Любая реализация, соответствующая данной спецификации, должна обеспечивать совместимость с другими соответствующими реализациями.
Соглашение о ключевых словах
Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL в настоящем документе следует интерпретировать в соответствии с RFC 2119 и RFC 8174, и они имеют нормативное значение только в том случае, когда выделены жирным шрифтом.
Структура документа
Настоящая спецификация состоит из 10 глав:
| Глава | Название | Область |
|---|---|---|
| Глава 1 | Обзор и позиционирование | Роль DTP, цели проектирования, связь с другими протоколами, управление версиями и совместимость (§1.7, нормативный) |
| Глава 2 | Терминология и определения | Нормативные определения терминов |
| Глава 3 | Архитектура протокола | Уровни протокола, компоненты и конечный автомат |
| Глава 4 | Структура логического фрейма | Бинарный формат заголовка и полезной нагрузки |
| Глава 5 | Механизм переговоров | Заключение, изменение и прекращение Agreement |
| Глава 6 | Передача данных | Рабочие процессы сбора и инжекции данных |
| Глава 7 | Безопасность и шифрование | Требования к сквозному шифрованию |
| Глава 8 | Надёжность | Возобновление, подтверждения и управление сессиями |
| Глава 9 | Обработка ошибок | Коды ошибок и механизм уведомлений |
| Глава 10 | Управление версиями | Операционные механизмы и поток управления управления версиями (авторитетная политика в главе 1 §1.7) |
Соответствие
Любая сущность, претендующая на реализацию DTP (далее — «реализация»), MUST удовлетворять следующим требованиям соответствия:
- Реализация MUST полностью поддерживать все правила MUST, определённые в настоящей спецификации.
- Реализация SHOULD поддерживать все правила SHOULD, определённые в настоящей спецификации. При отсутствии поддержки реализация MUST явно отразить это отклонение в своей документации.
- Реализация MAY самостоятельно решать, поддерживать ли правила MAY.
- Реализация MUST NOT вводить расширения, конфликтующие с настоящей спецификацией. Любое расширение MUST реализовываться через механизмы расширения, определённые в настоящей спецификации (см. кастомные поля в главе 4 и расширения параметров Agreement в главе 5).
Нормативные ссылки
- RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
- RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
- RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace (используется для Fragment_ID, Agreement_ID, Session_ID)
- RFC 3339 — Date and Time on the Internet: Timestamps (формат UTC-меток времени)
- CAP Specification — Control Authorization Protocol; DTP опирается на CAP в части аутентификации и обмена ключами
Связанные документы
- DTP Blueprint (
docs/ru/blueprint/): ненормативные вводные материалы по DTP, содержащие мотивацию, обоснование проектных решений и примеры - DTP Schema (
schema/draft/schema.ts): эталонные определения типов TypeScript для DTP