СПЕЦИФИКАЦИЯ

Faying Protocol/1.0 — §1 Обзор

Навигация по тексту протокола: Оглавление | следующая §2 Архитектура

§1 Обзор

Эта глава задаёт наименование протокола, его позиционирование, каркас целей проектирования, ключевые отличия от существующих схем, определение Faying Protocol одним предложением, объём поставки и не-цели данного текста протокола, а также правила управления версиями и совместимости. Эта глава — семантический якорь для следующих далее §2–§11 и приложений A/B.

Примечание о трассируемости EARS: за каждым правилом этой главы следует строка Trace:, перечисляющая соответствующие идентификаторы подпунктов EARS (из базы требований) в форме R<requirement>.<criterion>.<clause>.

§1.1 Наименование протокола

Имя спецификации протокола: Faying Protocol. Номер версии единообразно записывается как Faying Protocol/1.0.

Этот протокол упраздняет аббревиатуру FAP (Faying Auth Protocol) — имя протокола — Faying Protocol, отдельной аббревиатуры нет; если нужна краткая форма, используйте полное имя «Faying Protocol». Этот проектный документ и сопутствующие спецификационные документы более не содержат никаких исторических форм наименования, таких как FAP / FAP/1.0 / Faying Auth Protocol / application/fap+json / POST /fap/v1/.... Любые прежние ссылки на FAP следует понимать как устаревшие ссылки на Faying Protocol и заменять на Faying Protocol в новых документах.

Историческое наследие наименования: в ранних черновиках использовалось «Faying Auth Protocol (FAP)». Это наименование упразднено; любую внешнюю ссылку на FAP следует понимать как устаревшую ссылку на Faying Protocol, и она не должна повторно использоваться в новых документах.

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

Faying Protocol — это протокол прикладного уровня «непрерывного уровня авторизации» поверх TLS, несущий семантику того, «при каком состоянии присутствия, в каком объёме, на каком уровне и в каком временном окне Human Prime авторизует свою iFay».

Ниже TLS: конфиденциальность канала и идентичность пира обеспечивает TLS 1.3 (с опциональным mTLS); Faying Protocol не делает этого повторно.
Рядом с OAuth/OIDC: OAuth предоставляет авторизацию на уровне приложения, OIDC выпускает утверждения об идентичности; обе схемы — модели «мгновенного токена». Faying Protocol решает то, что не решает ни одна из них, — непрерывное агентство + привязку к присутствию + переключение уровней + уникальную подотчётность.
Выше WebAuthn: WebAuthn / FIDO2 предоставляет аппаратного уровня доказательства «присутствия пользователя» для Human Prime во время начальной инициализации (bootstrapping); Faying Protocol переиспользует его форму учётных данных как корень производного доверия.

Faying Protocol не заменяет TLS и не переизобретает OAuth; он располагается выше TLS и ниже бизнес-семантики, вынуждая каждое исходящее действие iFay проходить через шлюз проверки Mandate. Любой исходящий вызов, обходящий этот шлюз, рассматривается как Rogue Action и должен отклоняться промежуточным слоем (middleware), расположенным выше транспортного уровня и ниже бизнес-уровня.

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

В таблице ниже перечислены 8 целей проектирования G1–G8 Faying Protocol (основные цели) и 2 инженерные цели, производные от §9 / §5 (свойства безопасности / совместимость протокола). Каждая цель соответствует ровно одному Requirement в базе требований, формируя якорь двунаправленной трассируемости между этим текстом протокола и документом требований.

Цель	Смысл	Источник в концепции	Соответствующий Requirement
G1 Уникальная подотчётность	В любой момент исходящее действие iFay может быть однозначно отнесено к единственному Human Prime	Этический нижний предел, глава 13	Requirement 1
G2 Отказ по умолчанию (Default-Deny)	Нет действующего Mandate → нет исходящего действия; любое отсутствующее поле → отклонить	Поведение Rogue по умолчанию, глава 13	Requirement 2
G3 Наблюдаемость, аудируемость, отзываемость	Переходы состояний, инициирование действий, события продления/отзыва — все наблюдаемы, аудируемы и независимо проверяемы	Главы 11, 13	Requirement 3
G4 Симметричный отзыв	Достижимость путей отзыва ≥ достижимости путей установления; отзыв необратим	Главы 10, 12	Requirement 4
G5 Непрерывная калибровка	Сигналы присутствия и уровень Mandate могут переподтверждаться в каждый момент; доверие никогда не сохраняется дольше срока истечения	Главы 11, 12	Requirement 5
G6 Уровневая авторизация	Единственный Mandate не может представлять все степени строгости; уровень должен быть выражаем, переключаем, понижаем; повышения требуют свидетельства HP	Пункт 3 исходного брифа	Requirement 6
G7 Межустройственный вывод	Когда одна и та же iFay работает на разных терминалах, доверие может выводиться, но ответственная сторона никогда не меняется; объём/уровень строго сходятся	Эволюционный резерв фаз 2/3	Requirement 7
G8 Постквантовая эволюционируемость	Наборы алгоритмов можно согласовывать и накатывать вперёд; зарезервированы биты согласования PQC	Общее инженерное требование	Requirement 8
—(производная) Свойства безопасности	Защита от replay / захвата / фишинга / выявление обрыва / Adversarial Threats эпохи ИИ	§9 Вопросы безопасности	Requirement 9 (с производным Requirement 13)
—(производная) Совместимость протокола	Эквивалентность CBOR / JSON, Deterministic CBOR, кросс-реализационная матрица совместимости	§5 Сообщения протокола	Requirement 10

Принцип однозначного соответствия «Цель ↔ Requirement»: эта таблица — единственное авторитетное сопоставление между текстом протокола и документом требований. Любой идентификатор подпункта EARS R<n>.<m>.<k>, цитируемый в последующих главах при изложении инварианта или механизма, должен иметь корневой номер Requirement <n>, попадающий в столбец «Соответствующий Requirement». Endorsed_Mandate (Requirement 11), производный от G6 / G4 / G5 / G7, политика обрыва связи (Requirement 12) и защита эпохи ИИ (Requirement 13) выступают как уточнения G1–G8 и получают приземление на уровне протокола соответственно в §4 / §8 / §9.

§1.4 Ключевые отличия от существующих схем (версия в одну строку)

Существующая схема	Решает	НЕ решает — что должен решить Faying Protocol
OAuth 2.0 / 2.1	Авторизацию доступа приложения к ресурсам	Одноразовый токен, без уровня, без присутствия, без симметричного отзыва
OIDC SSO	Утверждение об идентичности (кто)	Нет непрерывного агентства (действия от имени), нет уровня
mTLS	Идентичность пира на обоих концах канала	Не может выразить «кто, при каком состоянии присутствия, кому делегировал что делать»
JWT	Самодостаточные утверждения с подписью	Нет отзыва, нет семантики уровня, долгий срок жизни конфликтует с «симметричным отзывом»
FIDO2 / WebAuthn	Аппаратного уровня доказательство присутствия для Human Prime	Покрывает только момент входа, а не непрерывное агентство iFay
Macaroons	Выводимые токены с оговорками (caveats)	Нет привязки к присутствию, нет явного свидетельства Human Prime
SPIFFE / SPIRE	Идентичность рабочей нагрузки	Взгляд со стороны нагрузки, без человеческой конечной точки ответственности

Faying Protocol не конкурирует ни с одним из перечисленного — он располагается выше TLS и ниже бизнес-семантики, поставляя специализированную семантику «Human Prime ↔ iFay»: непрерывное агентство + привязка к присутствию + переключение уровней + уникальная подотчётность + симметричный отзыв.

§1.5 Определение одним предложением

Faying Protocol = «Mandate (вместо токена) + Presence Signal + Attestation Chain + Revocation Registry» — четыре элемента, выражаемые совместно поверх TLS, инициируемые двунаправленно со стороны Human Prime и iFay, вступающие в силу только при явном подтверждении Human Prime, непрерывно калибруемые и симметрично отзываемые.

§1.5.1 Изменения состояния Faying вступают в силу только при явном подтверждении Human Prime (основное утверждение)

Инициирование Faying-отношения (установление или корректировка) является двунаправленным:

Инициировано HP: Human Prime может проактивно инициировать Faying через канал BOOTSTRAP (см. §2.4 Фаза A, §5.3.1).
Инициировано IF: iFay может проактивно запрашивать Faying у Human Prime (то есть FAYING_REQUEST) по двухшаговому пути §2.4 Фаза A0 → BOOTSTRAP (см. §5.3.6).

Тем не менее, независимо от того, какая сторона инициирует, окончательным условием вступления в силу любого изменения состояния Faying является то, что Human Prime выдаёт явное, необманутое, проверяемое подтверждение (форма по умолчанию — утверждение присутствия пользователя WebAuthn или эквивалентное доказательство аппаратного уровня).

Из этого немедленно следуют три нерушимых жёстких ограничения:

iFay в одиночку не может ввести Faying в силу: инициированный IF FAYING_REQUEST, не получивший явного подтверждения HP в течение BootstrapTimeout (по умолчанию 60 с, см. Приложение B), истекает или отклоняется и не производит никакого изменения состояния Faying. Mandate_Service должен вернуть E_FAYING_REQUEST_NOT_CONFIRMED (код ошибки 1014) и записать событие в Attestation Chain, чтобы сохранить необратимое свидетельство того, «кто инициировал, когда подтверждено, вступило ли в силу».
- Trace: R1.3.2 (инициированный IF путь вступает в силу только после явного подтверждения HP), R1.3.3 (отклонение без изменения состояния при истечении BootstrapTimeout без подтверждения), R1.3.4 (событие записывается в AC независимо от вступления в силу).
Нет пути суррогатного свидетеля: на уровне протокола не существует легитимного пути для iFay, Mandate_Service или Supervisory_Agent заменить Human Prime в завершении подтверждения Faying. Любой BOOTSTRAP без human_witness либо с непрошедшим проверку human_witness должен отклоняться с E_HUMAN_WITNESS_REQUIRED (код ошибки 1010).
- Trace: R1.3.5 (нет легитимного пути для IF / MS / SA заменить HP в завершении подтверждения Faying).
iFay не может в одностороннем порядке обойти отзыв: iFay может выпустить сообщение «запрос на разрыв Faying» (рассматриваемое как Disclosure_Report), но iFay не обладает полномочием отозвать собственный Mandate; любой отзыв должен в конечном счёте инициироваться Human Prime либо регулятором/уполномоченным органом и становиться видимым через канал представления HP (см. §4 / §10).
- Trace: R4.1.4 (IF не обладает полномочием отозвать собственный Mandate), R4.1.5 (запрос на разрыв записывается как Disclosure_Report в AC и проталкивается в канал представления HP).

Этот подраздел — единый якорь в главе «Обзор» для §2.4 Фаза A0, §5.3.6 FAYING_REQUEST и §5.4 кодов ошибок 1010 / 1014, а также отправная точка для всех последующих глав в аргументации «нет свидетельства HP — нет Faying».

§1.6 Объём поставки протокола и не-цели

§1.6.1 В объёме (Нормативно — несёт этот текст протокола)

Этот текст протокола (то есть данный единственный файл) специфицирует, и только специфицирует, следующее:

Объекты данных протокола: основной формат CBOR и резервный формат JSON для Mandate / Presence_Signal / Attestation / SignatureBundle / Faying Protocol Envelope / Endorsed_Mandate / Disclosure_Report и т. д. (CDDL авторитетен; см. §4 / §5).
- Trace: R10.1.1, R10.1.2, R10.2.1–R10.2.4.
Интерфейсы компонентов протокола: границы ответственности и инварианты Mandate_Service / Presence_Channel / Attestation_Chain / Revocation_Registry / Liveness_Channel / Behavior_Baseline_Service (см. §3).
Сообщения протокола: определения полей, коды ошибок и жёсткие ограничения на уровне протокола для семи типов сообщений BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE / FAYING_REQUEST / DISCLOSURE (см. §5).
Криптографические правила: согласование набора алгоритмов, иерархия вывода ключей, канонизация входа подписи (включая якорь входа подписи Endorsed_Mandate; см. §6).
- Trace: R8.1.1–R8.1.4, R8.2.1–R8.2.4.
Семантика уровней авторизации: точные определения пяти уровней G0–G4, матрица условий-триггеров, принцип монотонности понижения и подуровни Endorsement Grades (см. §7).
- Trace: R5.1.1, R6.1.1, R6.1.2.
Жизненный цикл и конечный автомат: семь состояний Unpaired / Pairing / Active / Degraded / Disconnected / Suspended / Revoked, условия их переходов и транзакция сверки (см. §8).
Вопросы безопасности: модель угроз STRIDE, защита от replay / захвата / фишинга / выявление обрыва, межустройственный перенос производного доверия и Adversarial Threats эпохи ИИ T1–T7 (см. §9).
Обработка ошибок: ответы протокола, пути восстановления, ограничения наблюдаемости и конвергенция Default-Deny для 14 кодов ошибок (включая 1010 E_HUMAN_WITNESS_REQUIRED, 1013 E_ENDORSEMENT_INVALID, 1014 E_FAYING_REQUEST_NOT_CONFIRMED; см. §10).
- Trace: R2.1.1–R2.1.4 (Default-Deny), R3.3.1 (канал представления HP обязан достигнуть).
Приложения: краткий справочник выравнивания терминологии (Приложение A), бюджеты параметров по умолчанию (Приложение B).

§1.6.2 Вне объёма (Ненормативно — не несётся этим протоколом)

Следующее не входит в нормативный объём этого текста протокола и служит лишь как референсные реализации / инженерные рекомендации; оно не связано с соответствием совместимости относительно данного текста протокола:

Бизнес-семантика: конкретное бизнес-поведение iFay, драйверы терминалов, паттерны интеграции приложений;
Дизайн UI / UX: конкретное представление канала представления Human Prime, дизайн диалогов подтверждения, мобильные / десктопные взаимодействия;
Эксплуатация и развёртывание: модели высокодоступного развёртывания, стратегии масштабирования, межрегиональная синхронизация для Mandate_Service / Revocation_Registry;
Детали транспортного уровня: детали рукопожатия самого TLS 1.3 (специфицируется RFC 8446), конкретные параметры тюнинга для HTTP/2 / gRPC / QUIC;
Реализации PD (Presence Device): аппаратные реализации WebAuthn authenticator / TPM / Platform Keystore (специфицируются W3C / ISO / TCG);
Юридические и комплаенс-детали: то, как регуляторы / органы комплаенса выступают юридическими «уполномоченными органами» вне протокола (уровень протокола специфицирует лишь их положение в перечислении RevokeReason и требование к цепочке подписи, но не их юридическое устройство);
Код референсной реализации: любая референсная реализация этого протокола (например, представление TypeScript schemas/types.ts или набор тестов на основе свойств pbt/) явно помечена как «Референсная реализация, не нормативно» и не составляет текст протокола;
Открытые вопросы: все пункты §11 Открытые вопросы со status: open.

§1.6.3 Принцип однофайловой поставки

Текст протокола — это данный единственный файл docs/en/specification/2025-10-25/Faying-Protocol-1.0.md.

Прочие Markdown-файлы в docs/en/specification/2025-10-25/ являются лишь вспомогательными документами (README / CHANGELOG) и не составляют текст протокола. Обратите внимание, что две стороны структурно асимметричны: английская сторона — это единственный файл (Faying-Protocol-1.0.md, с включёнными §1–§11 и приложениями A/B), тогда как китайская сторона в docs/zh-CN/specification/2025-10-25/ разбита на 11 файлов глав плюс приложения A/B/C. Поэтому английский единственный файл выровнен с китайским набором глав на уровне якорей разделов (нумерация разделов, диаграммы Mermaid, блоки кода CDDL / TypeScript, таблица кодов ошибок и приложения A / B), а не файл-к-файлу; журнал изменений (Приложение C) поддерживается только на китайской стороне. При возникновении неоднозначности между китайской и английской формулировками преимущественную силу имеет китайская версия, а английская версия исправляется на следующем обзорном собрании.

§1.7 Управление версиями и совместимость

Этот раздел — авторитетное определение нумерации версий Faying Protocol. Номер версии — не просто маркер документации, это часть контракта совместимости: он появляется в проводном конверте, в схемах и при согласовании, и напрямую определяет, могут ли две независимые реализации общаться друг с другом. Поэтому этот раздел нормативен: реализации ДОЛЖНЫ интерпретировать номера версий и выполнять согласование версий по правилам ниже. Приложение C (журнал изменений) лишь фиксирует историю; оно не переопределяет эти правила.

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

Faying Protocol описывает версию спецификации тремя взаимно независимыми осями, которые НЕ ДОЛЖНЫ сливаться в одно число:

Ось	На какой вопрос отвечает	Форма	Носитель	Пример
Версия протокола (контракт совместимости)	Могут ли две реализации общаться	`MAJOR.MINOR`	проза / поле `version` проводного конверта / имя файла схемы	`Faying Protocol/1.0`
Статус документа (жизненный цикл)	Финализирована ли эта спецификация	перечисление	`status` во front matter	`Draft` / `Final` / `Deprecated` / `Obsolete`
Редакционная версия (errata и уточнения)	Какая текстовая ревизия в рамках одной версии протокола	дата выпуска	имя каталога выпуска / `date` во front matter	`2025-10-25`

Основное ограничение: только «версия протокола» MAJOR.MINOR попадает в проводной формат (поле version конверта, имена файлов схем). Статус документа и редакционная версия НЕ ДОЛЖНЫ попадать в проводной формат — это маркеры управления документацией, и они не участвуют в решениях о совместимости. Реализация НЕ ДОЛЖНА менять своё поведение при обработке сообщений из-за того, что статус документа или редакционная версия пира отличаются.

§1.7.2 Семантика `MAJOR.MINOR` версии протокола

Версия протокола записывается как Faying Protocol/MAJOR.MINOR, только с двумя уровнями и без PATCH — проводной формат и семантика совместимости различают лишь два уровня совместимости.

MAJOR (ломающее изменение): любое изменение, которое заставит пира, реализованного строго по старой спецификации, отклонить или неверно интерпретировать новые сообщения. Примеры: изменение семантики авторитетного поля CDDL из §4.2, удаление типа сообщения, переопределение семантики кода ошибки, изменение поглощающего состояния конечного автомата.
- Правило: поднять MAJOR, сбросить MINOR в ноль (например, 1.4 → 2.0).
- Совместимость: совместимость между разными MAJOR не гарантируется.
MINOR (обратносовместимое добавление): добавление, которое новая реализация может понять в старых сообщениях и которое старая реализация может безопасно игнорировать там, где не распознаёт опциональные элементы. Примеры: добавление опциональных полей, добавление сообщений или кодов ошибок, добавление записей в каталог угроз эпохи ИИ, добавление параметров приложения, добавление Correctness Properties.
- Правило: инкрементировать MINOR (например, 1.0 → 1.1).
- Совместимость: в рамках одного MAJOR более высокий MINOR ДОЛЖЕН оставаться обратносовместимым с более низкими MINOR.

Решающий тест (самопроверка реализатора): заставит ли изменение пира, реализованного строго по старой спецификации, отклонить или неверно интерпретировать новые сообщения?

Да → MAJOR;
Нет, но добавляет видимое в проводном формате содержимое → MINOR;
Меняет только текст, а не семантику проводного формата (исправления опечаток, добавленные примеры, прояснённая неоднозначность) → не менять версию протокола; использовать редакционную версию из §1.7.4.

Текущая базовая линия — Faying Protocol/1.0.

§1.7.3 Согласование версий и правила совместимости (Нормативно)

Согласование версий переиспользует тот же подход, что и согласование набора алгоритмов в §6.1 (каждая сторона объявляет, выбирается наивысшее совместно поддерживаемое значение). Реализации ДОЛЖНЫ:

Объявить: во время BOOTSTRAP клиент и сервер каждый объявляют свой набор поддерживаемых версий протокола (например, supported: [1.0, 1.1]).
Одинаковый MAJOR → наивысший MINOR: когда обе стороны разделяют MAJOR, они ДОЛЖНЫ выбрать наивысший MINOR, поддерживаемый совместно, как действующую версию сессии; реализация с более высоким MINOR ДОЛЖНА уметь обслуживать пира с более низким MINOR (обратная совместимость вниз до MAJOR.0).
Разные MAJOR → отклонить: когда общего MAJOR не существует, согласование не происходит; BOOTSTRAP ДОЛЖЕН отклоняться с E_PROTOCOL (код ошибки 1099); «наилучшее усилие» при деградированной совместимости не допускается.
Накатываемое обновление не должно ломать существующие Mandate: когда через согласование версий вводится новый набор алгоритмов по умолчанию или новый MINOR, существующие Mandate ДОЛЖНЫ оставаться проверяемыми до их not_after; обновление версии НЕ ДОЛЖНО аннулировать действующие в полёте валидные Mandate.
- Trace: R8.2.4 (накатываемое обновление через согласование версий без нарушения проверяемости существующих Mandate).
Обработка неизвестного более высокого MINOR: при получении сообщения, объявленного как тот же MAJOR, но с более высоким MINOR, чем собственный, реализация ДОЛЖНА интерпретировать его на своём наивысшем поддерживаемом MINOR и игнорировать опциональные поля, которые она не распознаёт (а не отклонять); это и есть рантайм-приземление обещания обратной совместимости MINOR.

§1.7.4 Редакционная версия и errata (Ненормативные изменения)

После финализации Faying Protocol/1.0 (Final) чисто текстовые errata неизбежны — исправления опечаток, добавленные примеры, прояснённая неоднозначность, исправленные внутренние ссылки. Такие изменения:

НЕ ДОЛЖНЫ менять номер версии протокола (это ложно заявило бы об изменении контракта совместимости);
якорятся датой выпуска: например, Faying Protocol/1.0 (2025-10-25) — первая финальная редакция 1.0; последующие errata порождают новый каталог выпуска (например, 2026-03-xx/), при этом версия протокола остаётся 1.0;
регистрируются в журнале изменений Приложения C под категорией Editorial, а переход редакции помечается через поле edition во front matter;
Жёсткое ограничение: редакционная версия может нести только ненормативные изменения. Любая модификация, затрагивающая семантику проводного формата, ДОЛЖНА поднять MINOR или MAJOR и НЕ ДОЛЖНА выпускаться замаскированной под редакционные errata.

§1.7.5 Куда попадает номер версии и примечания для реализаторов стандарта

В таблице ниже точно указано, куда попадает номер версии, чтобы реализаторы могли судить, какие различия влияют на совместимость, а какие нет:

Место	Что записывается	Примечания
Поле `version` проводного конверта (§5.2)	`"Faying Protocol/MAJOR.MINOR"`	только MAJOR.MINOR; без даты редакции, без статуса документа
Имя файла схемы (`fap-1.0.cddl` и т. д.)	следует `MAJOR.MINOR`	имя файла не меняется между редакционными версиями — errata не переименовывают `fap-1.0.cddl`, сохраняя стабильность существующих ссылок (сохранённый исторический префикс `fap` следует той же логике; см. Приложение C)
content-type (§5.1)	`application/faying-protocol+cbor` (или `+json`)	content-type идентифицирует семейство протоколов; параметр `version=` МОЖЕТ прикрепляться для маршрутизации на уровне шлюза как удобство развёртывания, но этот параметр не входит в семантику проводного формата и не влияет на решения о совместимости
`status` / `date` во front matter	статус документа / редакционная версия	маркеры управления документацией; не попадают в проводной формат; пир НЕ ДОЛЖЕН менять обработку сообщений на их основе
git-тег	`faying-protocol-v<MAJOR.MINOR>-<status>`	финализация `faying-protocol-v1.0-final`; снимок редакции `faying-protocol-v1.0-2026-03-xx`; тег ДОЛЖЕН одновременно покрывать текст + `vectors/` + `schemas/`, замораживая тройку совместимости вместе

Обязательные примечания для реализаторов стандарта:

Совместимость определяется только версией протокола: единственное основание для «можем ли мы общаться» — это MAJOR.MINOR. Статус документа пира (Draft/Final) и редакционная версия (дата выпуска) не меняют поведение совместимости — никогда не отклоняйте валидные сообщения пира лишь из-за того, что он помечен Draft или имеет более старую редакцию.
Одинаковый MAJOR должен быть обратносовместим: при реализации более высокого MINOR вы ДОЛЖНЫ также корректно обслуживать всех пиров с более низким MINOR начиная с MAJOR.0.
Не трактуйте errata как обновления: изменение даты каталога выпуска (редакционная версия) не означает, что протокол изменился; только изменение MAJOR.MINOR требует оценки влияния на совместимость.
Стабильность имени файла схемы: не полагайтесь на имя файла как кодировку редакции; errata одного и того же MAJOR.MINOR переиспользуют одноимённый файл схемы, различаясь по git-тегу / каталогу выпуска.
Нет обещания совместимости во время Draft: пока status: Draft, MAJOR.MINOR может корректироваться до заморозки; обещания совместимости MAJOR/MINOR этого раздела вступают в полную силу только после Final.